Cannot connect to remote pvserver from macOS client

ParaView Support
1

I am connecting to a remote pvserver running on a Linux cluster node via an SSH tunnel. I have built paraview 5.9.1 from source on the cluster node.

I can successfully create the tunnel, start pvserver on the node, and connect from a Windows 10 Paraview 5.9.1 client, but I cannot connect from a macOS 11.4 (Big Sur) Paraview 5.9.1 client. When attempting to connect from macOS, I get the error:

ERROR: In /opt/glr/paraview/paraview-ci/build/superbuild/paraview/src/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 781
vtkSocketCommunicator (0x600003c3aeb0): Could not receive tag. 1010580540

ERROR: In /opt/glr/paraview/paraview-ci/build/superbuild/paraview/src/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 535
vtkSocketCommunicator (0x600003c3aeb0): Endian handshake failed.

ERROR: In /opt/glr/paraview/paraview-ci/build/superbuild/paraview/src/Remoting/Core/vtkTCPNetworkAccessManager.cxx, line 333
vtkTCPNetworkAccessManager (0x600001b44900): 
**********************************************************************
Connection failed during handshake. vtkSocketCommunicator::GetVersion()
 returns different values on the two connecting processes
 (Current value: 100).
**********************************************************************

What causes this error code? Is there a way to workaround this issue?

Thanks,
Ben

2

Are you enterely sure these are the same version of ParaView ?

I have built paraview 5.9.1 from source on the cluster node.

Which option did you enable ?

3

Yes, I am certain they are the same version of ParaView. I built the server ParaView with the options:
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DPARAVIEW_USE_MPI=ON -DPARAVIEW_USE_QT=OFF -DCMAKE_INSTALL_PREFIX=/avatar/bwibking/paraview_install -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc -DPARAVIEW_USE_PYTHON=ON -DVTK_OPENGL_HAS_EGL=ON

4

Strange bug. Did you encounter this @cory.quammen ?

5

By any chance is the Mac an M1 chip?

6

I was able to do a reverse connection from 5.9.1 osmesa version to my Mac 5.9.1 client, not using a tunnel.

7

No, it’s an Intel MacBook Pro.

8

I installed the pre-compiled binary from ParaView-5.9.1-osmesa-MPI-Linux-Python3.8-64bit.tar.gz on my cluster and tried to connect, but I get the same error:

ERROR: In /opt/glr/paraview/paraview-ci/build/superbuild/paraview/src/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 781
vtkSocketCommunicator (0x6000035c2130): Could not receive tag. 1010580540

ERROR: In /opt/glr/paraview/paraview-ci/build/superbuild/paraview/src/VTK/Parallel/Core/vtkSocketCommunicator.cxx, line 535
vtkSocketCommunicator (0x6000035c2130): Endian handshake failed.

ERROR: In /opt/glr/paraview/paraview-ci/build/superbuild/paraview/src/Remoting/Core/vtkTCPNetworkAccessManager.cxx, line 333
vtkTCPNetworkAccessManager (0x6000012f7b80): 
**********************************************************************
Connection failed during handshake. vtkSocketCommunicator::GetVersion()
 returns different values on the two connecting processes
 (Current value: 100).
**********************************************************************
9

On the server side, it says:
channel 3: open failed: connect failed: Name or service not known

Could this be a hostname resolution issue, or other issue with the tunnel?

10

Arg, this was very annoying. It works only if I set up the tunnel using the fully-qualified domain name of the cluster node.

It would be nice if ParaView gave a more sensible error message in this case. I don’t understand why the tunnel needs to be set up this way, or why pvserver cares about the FQDN, though.

11

Most definitelly:
https://gitlab.kitware.com/paraview/paraview/-/issues/18171

12

That’s good to know this is being tracked in the case of an actual version mismatch. Do you know why setting up a tunnel using a different hostname than the one printed to stdout by pvserver causes a version mismatch error?

13

I’m afraid not, this would require much deeper investigation.