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.

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.

Pragma Systems Technical Support
13809 Research Blvd, #675
Austin, TX 78750
http://www.pragmasys.com

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?

+x

 

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?

Pragma Systems Technical Support
13809 Research Blvd, #675
Austin, TX 78750
http://www.pragmasys.com

+x

 

Technical Support Group (TSG) - 4/29/2018 7:11:09 PM

+x

 

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?

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.


Pragma Systems Technical Support
13809 Research Blvd, #675
Austin, TX 78750
http://www.pragmasys.com

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.



Pragma Systems Technical Support
13809 Research Blvd, #675
Austin, TX 78750
http://www.pragmasys.com

+x

 

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?

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.


Pragma Systems Technical Support
13809 Research Blvd, #675
Austin, TX 78750
http://www.pragmasys.com

+x

 

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.