Opened 5 years ago

Last modified 5 years ago

#4515 assigned defect

Creating meeting timed out making tunnel to server

Reported by: Tom Goddard Owned by: Tom Goddard
Priority: moderate Milestone:
Component: VR Version:
Keywords: Cc:
Blocked By: Blocking:
Notify when closed: rkimera@rhsp.org Platform: all
Project: ChimeraX

Description

Ssh command to make tunnel to server when starting meeting timed out after 5 seconds for meeting started in Mali to Uganda server setup by Rodgers Kimera.

Begin forwarded message:

From: Rodgers Kimera
Subject: RE: ChimeraX meeting feature issues with ACE Mali.
Date: April 14, 2021 at 6:27:33 AM PDT
To: Tom Goddard

Dear Tom,

Our error is different from the one you highlighted. It more looks at connection timing out.

<screenshot of error attached>

The same command succeeds when here in Uganda and fail for Mali.

I expected the 2 commands
meeting access acemali address 137.63.184.167 account tunnel key C:/Users/Public/tunnel-key.pem
meeting start testmeeting access acemali

to create a meeting called “testmeeting” for others to join.

Kindly advise.

Thank you.

Regards,
Rodgers

Attachments (1)

image003.png (87.5 KB ) - added by Tom Goddard 5 years ago.

Download all attachments as: .zip

Change History (3)

by Tom Goddard, 5 years ago

Attachment: image003.png added

comment:1 by Tom Goddard, 5 years ago

Begin forwarded message:

From: Tom Goddard
Subject: Re: ChimeraX meeting feature issues with ACE Mali.
Date: April 14, 2021 at 9:54:26 AM PDT
To: Rodgers Kimera

Hi Rodgers,

That error message when trying to start a ChimeraX meeting means that the ssh connection to the meeting server was not established within 5 seconds ("Connection timed out"). The 5 second timeout period was specified on the ssh command ChimeraX ran to try to create the tunnel to the server.

C:\Windows\System32\PpenSSH\ssh.exe -N -i C:/Users/Public/tunnel-key.pem -o ExitOnForwardFailure=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=no -R 52195:localhost:52194 tunnel@137.63.184.167

The first thing to try is to use a longer timeout when connecting to the server. This can be specified when you name the server with the meeting access command

meeting access acemali address 137.63.184.167 account tunnel key C:/Users/Public/tunnel-key.pem timeout 30

The "timeout 30" option will allow 30 seconds to connect when you start the meeting. If this works it will unfortunately take 30 seconds to start the meeting even if the connection is made faster. The ssh command does not give any indication that the connection was established so ChimeraX will wait the full 30 seconds before trying to use the connection and ChimeraX will just be frozen for those 30 seconds. That is why I have the default timeout set to 5 seconds.

If the longer timeout still does not work, then the ssh connection to the server is somehow blocked, maybe by a firewall. You can try running the ssh.exe command that ChimeraX uses from a Command Prompt to explore whether ssh can connect at all without using ChimeraX.

Let me know what you find. Thanks for debugging this!

Tom

comment:2 by Tom Goddard, 5 years ago

The meeting command does not have a good way to handle ssh timeouts. The meeting command uses a 5 second default timeout and when starting a meeting it hangs ChimeraX for the full 5 seconds because the ssh command subprocess has no way to tell ChimeraX that the tunnel has been established. Using a longer timeout, say 30 seconds, means ChimeraX will be hung for 30 seconds. If no timeout is specified I think ssh uses the default socket connection timeout of 70 seconds. Slow or unreliable meeting startup is a pretty big problem. Four ideas for solving it are all bad. There is an ssh -f option that causes ssh to background itself once the tunnel is made. This works by forking another process with the original ssh process exiting. This almost solves the problem except that ChimeraX then has no way to kill the ssh tunnel since its Popen instance exits and no process id is available for the backgrounded ssh. A second idea is to try to connect to the tunnel a few times a second until a connection succeeds. This has various problems -- like the port may be already in use so the tunnel fails but the query connection succeeds. A third solution is to use a Python ssh module (asyncssh) to make the tunnels which gives more detailed info about tunnel status. This could lead to ugly problems with Python handling threads very poorly. A fourth solution is to abandon ssh and write some server program that maybe uses port 443 (https / ssl). That is obviously a lot of work and leaves ChimeraX handling authentication and encryption instead of letting ssh do all that work it is well designed for.

Note: See TracTickets for help on using tickets.