Windows remote connection from SLED 12

Dear Friends,

We are exploring SLED 12 in our environment for desktop purposes. When I am trying to take a windows machine remotely using Remote desktop viewer from SLED, it cannot give any connection. Please suggest how to take remote desktops of windows machine or any best practices need to follow to access the windows remote desktop.

Thanks & Regards

The command to connect via RDP to a system is ‘rdesktop’. If you are
using that and it is not working then you likely need to tweak the windows
system to allow remote connections.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

rdesktop is not included in SLED 12. It was included in SLED 11 until SP2 then removed in SP3.

The executable behind the icon labelled ‘Remote Desktop Viewer’ in SLED 12 is vinagre.

mike@Unknown:~> grep  'Remote Desktop Viewer' /usr/share/applications/*desktop
/usr/share/applications/vinagre.desktop:GenericName=Remote Desktop Viewer
/usr/share/applications/vinagre.desktop:Name=Remote Desktop Viewer
/usr/share/applications/vinagre-file.desktop:Name=Remote Desktop Viewer
mike@Unknown:~> grep ^Exec /usr/share/applications/vinagre.desktop
Exec=vinagre %U

The executable in the FreeRDP package which replaced rdesktop is xfreerdp. You could try using that instead.

Are you certain the Windows machines are correctly configured to allow a connection? Do you get any error messages and if so, what are they?

I can’t use the remote desktop viewer on SLED 12 either. At first I thought it was because I was trying to connect to a RDP server on a non standard port (3389) and perhaps there was a bug with that or I was some how putting in the port syntax incorrectly.

I tried one that was listening on port 3389. Tested connection to these on CentOS and Windows rdp clients and they work. Just doesn’t on my patched SLED 12.

I would be extremely surprised if this product has been out for months and not working for other people. So Im thinking there might be some config at my end?

Would be awesome if some one can actually verify that the out of the box RDP clients works on SLED 12?

Remote server is listening btw

user@my-desktop:~/Desktop> telnet server 3389
Connected to server
Escape character is ‘^]’.

Symptoms I get with the client is when I find a legitimate connection is the client window goes black for about a second then the client comes back to its normal gray window. No error message box. Nothing.

A bogus connection (where I intentionally put in a screwy port just goes black)

A couple of thoughts that may or may not help:

  1. Run the command from the command line, as you may get output there
    which you do not see when calling it straight from the GUI.

  2. Be SURE that your windows boxes are not rejecting things. Newer (but
    not anywhere near new) versions of windows reject older RDP clients by
    default as I recall, so if you have them configured to not allow older RDP
    clients then you may not get more than a start of the connection followed
    by rejection. I THINK this will show up in STDOUT/STDERR so launching
    from the command line should help. If not the windows-side logs should
    indicate something too.

  3. Setup a LAN trace to see which side (client or server) is tearing down
    the connection.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

I’ve just been playing with this trying to connect to a Windows 7 machine. I got it to work by specifying ‘–sec rdp’ in the ‘Advanced options:’ field.

strace reveals that vinagre is actually calling the FreeRDP binary xfreerdp to do the connection, which makes my suggestion earlier in the thread to try FreeRDP instead of vinagre invalid.

This is yet another reason SLED12 is broken.

  1. You can install tsclient from the repos. tsclient requires rdesktop, which is no longer used or available in SLED12
  2. vinagre, the GUI that should work with xfreerdp (the replacement for rdesktop) doesn’t catch xfreerdp’s CLI interaction to enter the password or approve certificates if you aren’t using the old authentication method so you have to call vinagre from a CLI to use it.

I created a script that takes the arguments for rdesktop and runs xfreerdp instead so I could continue using tsclient, where all of my destinations are saved. I still have to run tsclient from a CLI to enter passwords.

Huh. This is an issue which has come up before because rdesktop was removed from SLED 11 as of SP3. The tsclient package on SLED 11 SP3 has been fixed.

[CODE]mike@linux:~> cat /etc/SuSE-release
SUSE Linux Enterprise Desktop 11 (x86_64)
mike@linux:~> rpm -q --changelog tsclient | head -4

  • Add support for freerdp (bnc#829415)
    • Added patch tsclient-freerdp-support.patch

mike@linux:~> [/CODE]

Somehow the tsclient package in SLED 12 hasn’t had the patch applied to it, strace shows it still looks for the rdesktop binary.

Yep, can reproduce that. It appears to be an upstream issue since there’s a bug report about it for Fedora
Last comment indicates bug is present in Red Hat Enterprise 7 too

I talked to someone about the tsclient issue when it was discovered in SLED 11 SP3 so I’ll see if I can raise it again via same channel. But if you can raise a Service Request and if not use Two reports get twice the attention than one. Maybe.