Pragma Systems Technical Forum

sftp -oConnectTimeout option

https://forums.pragmasys.com/Topic402.aspx

By alex qiu - 4/9/2018 8:53:36 PM

Hi there,

Am new to Pragma fortress app, while when migrating our sftp related app from Linux to Windows, we found that in Pragma fortress world there is no such "ConnectTimeout" option in sftp command.

We would like to know that how to setup a connection timeout in Pragma fortress world when using sftp connection, we need such setting in case the connection is hanged during establishing the connection.
By Technical Support Group (TSG) - 4/10/2018 9:16:56 AM

Hello,
I will discuss this request with our development team and get back to you. Our team tries to get new feature request like this one out quickly.
By emalinis - 4/27/2018 12:31:05 PM

Hi, in relation to this/Alex Qiu's post, what we are looking for is a "-oTransmitTimeout" setting/option.

What we have sometimes encountered is that during the transmission of a file with sftp.exe, the transmission just 'hangs', and sits there indefinitely.  We suspect that our client is not getting or is somehow losing the ACK packet from the server, so the sftp just waits forever.  What typically happens for us, is that the Windows task we are using to run the file transfer, reaches its defined maximum run time, so the task just gets killed when that happens, but this is not at all helpful and our sftp script does not get the opportunity to handle the issue gracefully.

So what we would like is to be able to set an option to specify the maximum amount of time for the sftp program to wait during a file transmission.  And then just produce an error and exit (or perhaps move onto the next file in a batch) if it reaches the timeout.

Can you pls advise whether we can have this feature as well (or if it already exists in some form - using 'keepalive' maybe?) in the sftp program?
By Technical Support Group (TSG) - 4/29/2018 1:11:09 PM

emalinis - 4/27/2018 6:31:05 PM
Hi, in relation to this/Alex Qiu's post, what we are looking for is a "-oTransmitTimeout" setting/option.

What we have sometimes encountered is that during the transmission of a file with sftp.exe, the transmission just 'hangs', and sits there indefinitely.  We suspect that our client is not getting or is somehow losing the ACK packet from the server, so the sftp just waits forever.  What typically happens for us, is that the Windows task we are using to run the file transfer, reaches its defined maximum run time, so the task just gets killed when that happens, but this is not at all helpful and our sftp script does not get the opportunity to handle the issue gracefully.

So what we would like is to be able to set an option to specify the maximum amount of time for the sftp program to wait during a file transmission.  And then just produce an error and exit (or perhaps move onto the next file in a batch) if it reaches the timeout.

Can you pls advise whether we can have this feature as well (or if it already exists in some form - using 'keepalive' maybe?) in the sftp program?

I've discussed your issue with our development team and their recommendation is that a timeout would not necessarily be a good solution for your situation. If the session has gotten into a state where packets cannot be transmitted, then the session should exit. We should try to determine why your session is hanging to see if the issue can be fixed, instead of a workaround for the issue.

Given that, have you done any logging on the server side or verbose logging on the client side to determine what is happening? Are you connecting with our server or client or both?
By emalinis - 4/30/2018 1:04:26 PM

Technical Support Group (TSG) - 4/29/2018 7:11:09 PM
emalinis - 4/27/2018 6:31:05 PM
Hi, in relation to this/Alex Qiu's post, what we are looking for is a "-oTransmitTimeout" setting/option.

What we have sometimes encountered is that during the transmission of a file with sftp.exe, the transmission just 'hangs', and sits there indefinitely.  We suspect that our client is not getting or is somehow losing the ACK packet from the server, so the sftp just waits forever.  What typically happens for us, is that the Windows task we are using to run the file transfer, reaches its defined maximum run time, so the task just gets killed when that happens, but this is not at all helpful and our sftp script does not get the opportunity to handle the issue gracefully.

So what we would like is to be able to set an option to specify the maximum amount of time for the sftp program to wait during a file transmission.  And then just produce an error and exit (or perhaps move onto the next file in a batch) if it reaches the timeout.

Can you pls advise whether we can have this feature as well (or if it already exists in some form - using 'keepalive' maybe?) in the sftp program?

I've discussed your issue with our development team and their recommendation is that a timeout would not necessarily be a good solution for your situation. If the session has gotten into a state where packets cannot be transmitted, then the session should exit. We should try to determine why your session is hanging to see if the issue can be fixed, instead of a workaround for the issue.

Given that, have you done any logging on the server side or verbose logging on the client side to determine what is happening? Are you connecting with our server or client or both?

Hi,
We are only using the Pragma sftp.exe as a client, and we have *not* turned on verbose mode (-v) logging due to the fact that the issue seems to only occur in our Production environment, and happens very rarely/randomly. So it's not something we can easily reproduce at will, and we're not certain whether verbose logging our client may have some side-effects(?) that we would not want to risk in Production. Additionally, we have no control on the sFTP server side, since they're a third-party and we don't know exactly what they are using as their sFTP server software (although somewhat certain it's not Pragma).

For troubleshooting, we've typically seen that the transmission progress of a file actually reaches 100%, but then at that point it seems to get 'stuck' waiting for something from the server. Unfortunately, given how rare/random the issue is, we can't really tell much more than that at this point.

Still, that said we don't know why the sftp.exe client is just waiting indefinitely. And even if you don't agree that a 'timeout' is the best solution, shouldn't the client have some better way of detecting that the file transmission wasn't successful? We agree that the client/session should exit in this case, but it doesn't seem to do that. Is there some way we can ensure that it does so under this scenario, or at least so the client doesn't just hang?

By Technical Support Group (TSG) - 4/30/2018 1:43:38 PM

The first thing to check is that you are using the latest sftp client. At the command prompt, type "which sshdll.dll -d" and "which sftp.exe -d". The commands will give you the version number of your client. If you are not running the latest build, then you can update at www.pragmasys.com/ssh-client/download. You can get the latest build on the same page.

I understand this is a production system, so you can install to a different machine, then copy the files, sftp.exe, ssh.exe, and sshdll.dll to the production server, saving your original programs. This will allow you to roll back if you have any issue.
By Technical Support Group (TSG) - 5/3/2018 8:38:51 AM

Alex,

The new feature you requested of -oConnectionTimeout has been implemented and is part of the new release.  You can download the server at www.pragmasys.com/ssh-server/download or the client only at www.pragmasys.com/ssh-client/download.

The feature is part of the client so you only have to install the client.

By emalinis - 5/3/2018 10:47:39 AM

Technical Support Group (TSG) - 4/30/2018 7:43:38 PM
The first thing to check is that you are using the latest sftp client. At the command prompt, type "which sshdll.dll -d" and "which sftp.exe -d". The commands will give you the version number of your client. If you are not running the latest build, then you can update at www.pragmasys.com/ssh-client/download. You can get the latest build on the same page.

I understand this is a production system, so you can install to a different machine, then copy the files, sftp.exe, ssh.exe, and sshdll.dll to the production server, saving your original programs. This will allow you to roll back if you have any issue.

Hi, we appear to be using 5.0.9.2904.  It will take us a bit of work to test and eventually deploy the latest/newer version.
In the meantime, could you pls kindly advise whether using the -okeepalive=yes option might help with our particular issue?
By Technical Support Group (TSG) - 5/3/2018 2:27:29 PM

You are running a very old build. Since there is no keepalive feature as of yet, you would have to update to the latest build anyway. I suggest you update to the latest release and see if that fixes your issue.
By alex qiu - 5/3/2018 7:30:49 PM

Technical Support Group (TSG) - 5/3/2018 2:38:51 PM
Alex,

The new feature you requested of -oConnectionTimeout has been implemented and is part of the new release.  You can download the server at www.pragmasys.com/ssh-server/download or the client only at www.pragmasys.com/ssh-client/download.

The feature is part of the client so you only have to install the client.


Hi team,

Thanks a million for the prompt action on this, will give it a try.
Cheers, have a nice day.
By Technical Support Group (TSG) - 5/3/2018 7:36:06 PM

Thank you. We strive to respond quickly to customer issues. Please let me know how things progress.
By alex qiu - 7/25/2018 3:48:15 AM

Hi team,

The project is held for some time and we resume it, we have tested the –oConnectionTimeout option but we don’t know how–oConnectionTimeout works, it didn’t stop in time when connecting to host, andit don’t stop when I remain idle after connection success.


The sample sftp connection command is like below with 10s timeout option:
sftp 12345678@certain-external-party.com -oConnectionTimeout=10s -oIdentityfile2=C:/xxx/.ssh/id_rsa -LC:\xxx\logs\sftp-ghss1.log

The result is that connecting to host take more than 10s, but anyway it success and we keep it idlefor more than 10s after connection success, it is not disconnected. The expected result is after 10s when connecting to remote (before sftp> shows), it will be disconnected with "connection time out" err message.

Am not sure how to make it work hence would like to ask you to shed some lights on us.
By Technical Support Group (TSG) - 7/25/2018 7:29:27 PM

alex qiu - 7/25/2018 9:48:15 AM
Hi team,

The project is held for some time and we resume it, we have tested the –oConnectionTimeout option but we don’t know how–oConnectionTimeout works, it didn’t stop in time when connecting to host, andit don’t stop when I remain idle after connection success.


The sample sftp connection command is like below with 10s timeout option:
sftp 12345678@certain-external-party.com -oConnectionTimeout=10s -oIdentityfile2=C:/xxx/.ssh/id_rsa -LC:\xxx\logs\sftp-ghss1.log

The result is that connecting to host take more than 10s, but anyway it success and we keep it idlefor more than 10s after connection success, it is not disconnected. The expected result is after 10s when connecting to remote (before sftp> shows), it will be disconnected with "connection time out" err message.

Am not sure how to make it work hence would like to ask you to shed some lights on us.

Your command line looks correct. Please add a -v to your command line to get verbose output. In the output, you should get a line that says "ConnectEx pending". If you do not get that line, then either you are not running the latest version or you are not getting the connection timeout parameter configured correctly.
By alex qiu - 8/1/2018 6:11:55 AM

Hi team,

Thanks a lot for the info, we have tested couple of cases on this and found it works perfectly when connect within internal network without proxy.

========= Quote start ==========
Pragma Fortress 5.0.10.1563
Reading configuration data C:\Users\appadm\AppData\Roaming\PragmaSSH\config
ConnectEx pending
wait ready!
ConnectEx succeeded
connect took 0 ms
Connection established.
timeout: 10000 ms remain after connect
========= Quote end  ==========

While when we connect to external vendor site using proxy config it not showing the "ConnectEx pending"
========= Quote start ==========
Pragma Fortress 5.0.10.1563
Reading configuration data C:\Users\appadm\AppData\Roaming\PragmaSSH\config
timeout: 10000 ms remain after connect
========= Quote end  ==========

The proxy config please see below:
Host host.blahblahblah.com
 ProxyCommand connect -S proxy.abc.local:1080 %h %p

Is there any advice from you? e.g. the connect.exe or the proxy config is having issue?
Am looking forward to getting your reply soon, thanks a lot in advance.
By Technical Support Group (TSG) - 8/2/2018 8:23:49 AM

alex qiu - 8/1/2018 12:11:55 PM
Hi team,

Thanks a lot for the info, we have tested couple of cases on this and found it works perfectly when connect within internal network without proxy.

========= Quote start ==========
Pragma Fortress 5.0.10.1563
Reading configuration data C:\Users\appadm\AppData\Roaming\PragmaSSH\config
ConnectEx pending
wait ready!
ConnectEx succeeded
connect took 0 ms
Connection established.
timeout: 10000 ms remain after connect
========= Quote end  ==========

While when we connect to external vendor site using proxy config it not showing the "ConnectEx pending"
========= Quote start ==========
Pragma Fortress 5.0.10.1563
Reading configuration data C:\Users\appadm\AppData\Roaming\PragmaSSH\config
timeout: 10000 ms remain after connect
========= Quote end  ==========

The proxy config please see below:
Host host.blahblahblah.com
 ProxyCommand connect -S proxy.abc.local:1080 %h %p

Is there any advice from you? e.g. the connect.exe or the proxy config is having issue?
Am looking forward to getting your reply soon, thanks a lot in advance.

Sorry for the delay. I am trying to duplicate the issue so I can determine the solution. I will get back to you as soon as possible.
By alex qiu - 10/7/2018 9:20:13 PM

Technical Support Group (TSG) - 8/2/2018 2:23:49 PM
alex qiu - 8/1/2018 12:11:55 PM
Hi team,

Thanks a lot for the info, we have tested couple of cases on this and found it works perfectly when connect within internal network without proxy.

========= Quote start ==========
Pragma Fortress 5.0.10.1563
Reading configuration data C:\Users\appadm\AppData\Roaming\PragmaSSH\config
ConnectEx pending
wait ready!
ConnectEx succeeded
connect took 0 ms
Connection established.
timeout: 10000 ms remain after connect
========= Quote end  ==========

While when we connect to external vendor site using proxy config it not showing the "ConnectEx pending"
========= Quote start ==========
Pragma Fortress 5.0.10.1563
Reading configuration data C:\Users\appadm\AppData\Roaming\PragmaSSH\config
timeout: 10000 ms remain after connect
========= Quote end  ==========

The proxy config please see below:
Host host.blahblahblah.com
 ProxyCommand connect -S proxy.abc.local:1080 %h %p

Is there any advice from you? e.g. the connect.exe or the proxy config is having issue?
Am looking forward to getting your reply soon, thanks a lot in advance.

Sorry for the delay. I am trying to duplicate the issue so I can determine the solution. I will get back to you as soon as possible.

Hi team,

Is there any update on this one? Thanks a lot in advance.
By Technical Support Group (TSG) - 10/8/2018 12:25:45 PM

Hello,

The developer has been working on this issue. I am not certain if there is a final fix on it or not. I will check and get back to you.
By alex qiu - 10/21/2018 8:36:54 PM

Technical Support Group (TSG) - 10/8/2018 6:25:45 PM
Hello,

The developer has been working on this issue. I am not certain if there is a final fix on it or not. I will check and get back to you.

Hi team,

Well, may I know the progress on this one?
By Technical Support Group (TSG) - 10/22/2018 11:16:22 AM

I am sorry that this is taking so long. The issue has been addressed and will be part of the next release. We are currently working on other issues that will be part of the next release as well. We are planning on a mid-November release.
By alex qiu - 11/21/2018 2:52:21 AM

Technical Support Group (TSG) - 10/22/2018 5:16:22 PM
I am sorry that this is taking so long. The issue has been addressed and will be part of the next release. We are currently working on other issues that will be part of the next release as well. We are planning on a mid-November release.

Hi team,

Glad to get the update, so may I know whether it's now ready for download?
If yes, please if you can provide the download link for the version?

Thanks a lot in advance.
By Technical Support Group (TSG) - 11/27/2018 4:03:32 PM

alex qiu - 11/21/2018 8:52:21 AM
Technical Support Group (TSG) - 10/22/2018 5:16:22 PM
I am sorry that this is taking so long. The issue has been addressed and will be part of the next release. We are currently working on other issues that will be part of the next release as well. We are planning on a mid-November release.

Hi team,

Glad to get the update, so may I know whether it's now ready for download?
If yes, please if you can provide the download link for the version?

Thanks a lot in advance.
Hello,

The fix has been deployed. Thank you so much for your patience. You can download the server at www.pragmasys.com/ssh-server/download and the client at www.pragmasys.com/ssh-client/download.

By rostant - 12/19/2019 6:36:36 AM

Hi all,
we appear to be using 5.0.9.2904. It will take us a bit of work to test and eventually deploy the latest/newer version.
In the meantime, could you pls kindly advise whether using the -okeepalive=yes option might help with our particular issue?
By Technical Support Group (TSG) - 12/19/2019 9:56:01 AM

rostant - 12/19/2019 12:36:36 PM
Hi all,
we appear to be using 5.0.9.2904. It will take us a bit of work to test and eventually deploy the latest/newer version.
In the meantime, could you pls kindly advise whether using the -okeepalive=yes option might help with our particular issue?

Hello,

The keepalive feature is opposite of the timeout feature. It would send a signal to the server to keep the session active.