RHEL + turboVNC, teamviewer version 12, 13, 14 will not allow connections

Announcements

A new TeamViewer version for Windows has been released. Read the Change Log for 15.7.7 here!

Highlighted
Posted by
Digon

RHEL + turboVNC, teamviewer version 12, 13, 14 will not allow connections

I have been using TeamViewerQS 11 on a RHEL 7 machine for years without issue. I have sucessfully connected to this machine using various version of the Mac OS license without issue (v11, 12, 13, 14) until recently. Now my Mac client is only allowing me 5 minute connections as the remote server will be deprecated soon.

I have installed (using the yum repository) and the x86 tar balls the Linux teamview client (quick support as a seperate package seems to have disappeared), versions 12, 13, and 14. It shoudl be noted that this remote (Linux) machine is a headless CAD machine that relies of turboVNC for graphics. I cannot run the Linux teamviewer binaries successfully without using vglrun; if I attempt to run the v12, v13, or v14 teamviewer binaries on the remote Linux machine without vglrun, the window that should contian the lincense and agreement buttons flashes up and them disappears (this is being run over a very low-rate VNC connection).

When I do start teamviewer with vglrun, I am presented with the license agreement window, I can accept the license, and I am then presented with the normal TeamViewer window with the newly populated host ID and password, along with the green dot indicated the host is ready to accept a client connection. However, none of these version will allow me to connect from my Mac (Mac Version's 14 and 11). I always receive an error indiciated that a connection cannot be opened becasue teamviewer is not running on the host (it is).

My present options are to abandon TeamViewer entirely and just VNC (extremely slow) or only have five minutes of connectivity at a time.

I am using the free license (graduate student, personal use), but I'd be willing to upgrade if I knew this worked.

 

3 Replies
3 Replies
Highlighted
Posted by
Digon

Re: RHEL + turboVNC, teamviewer version 12, 13, 14 will not allow connections

Folks,

I am providing some more information here. There are really a couple of issues here.

My setup: RHEL 7 as a remote host that I want to connect to. I use TurboVNC version 2.1 and VirtualGL 2.5 on this machine to support headless VNC and OpenGL required by a number of CAD tools. I an not a root on this machine, so I'd prefer to use a tar ball installation. I have a new TV 14 tar bakll installation on this machine. I am trying to connect to this machine using TV 14 from my Mac.

This has worked without issue using TVQS 11 for a couple of year now without issues. I am now forced to upgrade to a newer remote host version. Now, using v14 on the Linux remote host, the software either will not start up or it will start but not allow a connection from my remote client (my Mac).

The installation on the Linux box indicates that the libraries are all fine:

 

  -=-   TeamViewer tar.xz check   -=-      

  In order to use the tar.xz version of TeamViewer, 
  you have to make sure that the necessary libraries are installed.

    Writing raw output to /homes/holloway/Downloads/v14/teamviewer/logfiles/DependencyCheck.log

 Analyzing dependencies ...            

	All library dependencies (*.so) seem to be satisfied!

	QtQuickControls seems to be installed

1) starting TV14 on Linux without VirtualGL will simply crash.  Here's the terminal output:

 

 

Init...
CheckCPU: SSE2 support: yes
Checking setup...
Launching TeamViewer ...
Starting network process (no daemon)
Network process started (19184)
Launching TeamViewer GUI ...
Abort (core dumped)

 

I've included the gui.log information: 

QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize 8, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DefaultSwapBehavior), swapInterval 1, profile  QSurfaceFormat::OpenGLContextProfile(NoProfile)) 

The startup.log file doesn't seem to indicate anything odd:

Init...
TeamViewer:        14.2.8352 - TAR_NI
Profile:           /homes/myuname (myuname)
Desktop:           DS: '' 	XDG: 'MATE'
XServer TTY:       none

ok (info)

CheckCPU: SSE2 support: yes
FONTCONFIG_FILE: /homes/myuname/Downloads/v14/teamviewer/tv_bin/script/fonts_portable.conf
ok (profile)

#2) if I actaully start teamviewer using VirtualGL (

$vglrun teamviewer

) , the gui starts up fine, I can accept the license agreement. The GUI comes up and indiciates everything is fine. I cannot, however, connect from my remote machine (Mac). Here's a screen shot of the Mac dialog with the error messages:TV14_Fail.jpg

Here is the gui.log output. This includes when I manually close the remote (linux) TV window following no conenction from my Mac:

QSGContext::initialize: stencil buffer support missing, expect rendering errors
QSystemTrayIcon::setVisible: No Icon set
[VGL] ERROR: in getGLXDrawable--
[VGL]    184: Window has been deleted by window manager
QObject::~QObject: Timers cannot be stopped from another thread
QObject::~QObject: Timers cannot be stopped from another thread
terminate called without an active exception

and here is the startup log:

Init...
TeamViewer:        14.2.8352 - TAR_NI
Profile:           /homes/myuname (myuname)
Desktop:           DS: '' 	XDG: 'MATE'
XServer TTY:       none

ok (info)

CheckCPU: SSE2 support: yes
FONTCONFIG_FILE: /homes/myuname/Downloads/v14/teamviewer/tv_bin/script/fonts_portable.conf
ok (profile)

 

I can supply the TeamView14_LogFile data as well.

 

-JH

 

 

Highlighted
Posted by
Digon

Re: RHEL + turboVNC, teamviewer version 12, 13, 14 will not allow connections

Does anyone from the TV team have any input here?

Highlighted
Posted by
Henagon

Re: RHEL + turboVNC, teamviewer version 12, 13, 14 will not allow connections

Teamviewer staff is ignoring this forum. It's simply of a way for them to let the users "vent out" instead of actually solving their issues.