# GetVersion() returns different values on the two connecting processes
**URL:** https://discourse.paraview.org/t/getversion-returns-different-values-on-the-two-connecting-processes/14478
**Category:** ParaView Support
**Created:** [April 24, 2024, 3:17pm UTC](https://discourse.paraview.org/t/getversion-returns-different-values-on-the-two-connecting-processes/14478 "2024-04-24T15:17:14Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@jfavre](https://discourse.paraview.org/u/jfavre)
#### Post date: [April 24, 2024, 3:17pm UTC](https://discourse.paraview.org/t/getversion-returns-different-values-on-the-two-connecting-processes/14478/1 "2024-04-24T15:17:14Z")
I have a ParaView server (v5.12.0) installed on a remote cluster. I can connect to it from any Linux and Mac boxes using reverse connections and ssh tunnels. That’s the good part.
I **cannot** connect from Windows, using the power shell to set up my keys, etc.
I have verified that from my Power shell, I can set up the reverse tunnel and get to the server. The jobs are launched and they continue to fail with the error “Connection failed during handshake. vtkSocketCommunicator::GetVersion()
returns different values on the two connecting processes”. That error message is not right. I do have the same versions on both sides. In fact, I can connect using a forward tunnel to the login node, submit a job, forward the tunnel to the compute node, and my Windows client connects to the waiting pvserver.
in summary, the reverse connection over ssh tunnel works well for Linux and Mac clients. It does not for a Windows client, complaining that versions are mis-matched. Yet, the same Windows client can connect with a forward tunnel. So, at the very least, the error message should try to be more informative. Is there some debug flags/options I can use to get to the _real_ symptoms?
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [April 24, 2024, 3:20pm UTC](https://discourse.paraview.org/t/getversion-returns-different-values-on-the-two-connecting-processes/14478/2 "2024-04-24T15:20:57Z")
probably a symptom of this issue:
>
>
> \*\*Server OperatingSystem\*\*
> any linux based os
>
> \*\*Client OperatingSystem\*\*
> Wi…ndows 10 with Spring Update
>
> \*\*What is failing\*\*
> There is definitely a bug in Microsoft OpenSSH implementation from 2018 Spring Update.
>
> How to test it :
> On the local (Windows 10), install Python3, Putty and make sure ssh is available.
> Then
>
> 1. Run a python http server in a terminal (on port 8000 by default)
>
> \`python -m http.server\`
>
> 2. Create a reverse connection ssh tunnel
>
> \`ssh -R 8080:localhost:8000 user@remote\`
>
> On the remote, connect trough the tunnel with telnet
> On The remote, connect to it trough telnet
>
> \>telnet localhost 8080
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^\]'.
> Connection closed by foreign host.
>
> The tunnel is still runnning but telnet disconnect almost instantly after the connection.
>
> If you replase \`ssh\` by the plink.exe from putty, it works flawlessly and you can connect with a browser.
>
>
> \*\*Expected output\*\*
> \`\`\`
> \>telnet localhost 8080
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^\]'.
> \`\`\`
>
> \*\*Actual output\*\*
> \`\`\`
> \>telnet localhost 8080
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^\]'.
> Connection closed by foreign host.
>
> \`\`\`
---
### Author:  [@jfavre](https://discourse.paraview.org/u/jfavre)
#### Post date: [April 25, 2024, 6:56am UTC](https://discourse.paraview.org/t/getversion-returns-different-values-on-the-two-connecting-processes/14478/3 "2024-04-25T06:56:42Z")
@mwestphal . You are the best! the tips you sent suggested to change localhost by 127.0.0.1 and it resolved the problem. Thanks a bunch.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [April 25, 2024, 6:57am UTC](https://discourse.paraview.org/t/getversion-returns-different-values-on-the-two-connecting-processes/14478/4 "2024-04-25T06:57:19Z")
Indeed, this is related to ipv4 and ipv6 🙂