|
Technical Support Group...
|
|
|
Group: Moderators
Posts: 144,
Visits: 648
|
+xHi 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.
Pragma Systems Technical Support 13809 Research Blvd, #675 Austin, TX 78750 http://www.pragmasys.com
|
|
|
|
|
alex qiu
|
|
|
Group: Forum Members
Posts: 17,
Visits: 85
|
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.
|
|
|
|
|
Technical Support Group...
|
|
|
Group: Moderators
Posts: 144,
Visits: 648
|
Thank you. We strive to respond quickly to customer issues. Please let me know how things progress.
Pragma Systems Technical Support
13809 Research Blvd, #675
Austin, TX 78750
http://www.pragmasys.com
|
|
|
|
|
alex qiu
|
|
|
Group: Forum Members
Posts: 17,
Visits: 85
|
+x Hi team, Thanks a million for the prompt action on this, will give it a try. Cheers, have a nice day.
|
|
|
|
|
Technical Support Group...
|
|
|
Group: Moderators
Posts: 144,
Visits: 648
|
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
|
|
|
|
|
emalinis
|
|
|
Group: Forum Members
Posts: 7,
Visits: 17
|
+xThe 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?
|
|
|
|
|
Technical Support Group...
|
|
|
Group: Moderators
Posts: 144,
Visits: 648
|
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
|
|
|
|
|
Technical Support Group...
|
|
|
Group: Moderators
Posts: 144,
Visits: 648
|
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
|
|
|
|
|
emalinis
|
|
|
Group: Forum Members
Posts: 7,
Visits: 17
|
+x+xHi, 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?
|
|
|
|
|
Technical Support Group...
|
|
|
Group: Moderators
Posts: 144,
Visits: 648
|
+xHi, 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
|
|
|
|