Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

rtgill

well, after several visits from the cable company, and alot of runaround from
tech support, they finally admitted that they had a problem with there UBR cisco
modems.Transfer rates are back to normal with no server timeouts...
rtgill

Re: SCP/SFTP transfers timing out

Oversea Site wrote:

runderwo wrote:

Anyone know why SCP and SFTP transfers would time out every 50 megs or so and require the user to resume? It can be reproduced with fairly good accuracy. I'm not familiar enough with SSH protocol to even make any guesses here... but this makes it quite difficult to complete any large transfers.


You should set your xDSL/Cable Network Card MTU Value to 1400 or 1300. It will fix your timeout problem.


I have set my MTU value to 1300 with scp/sftp protocol, and changed default to 30 sec. timeout.. There is no change, server still times out.....!

can any one explain this? Is this a provider issue?

thanks rick
Oversea Site

Re: SCP/SFTP transfers timing out

runderwo wrote:

Anyone know why SCP and SFTP transfers would time out every 50 megs or so and require the user to resume? It can be reproduced with fairly good accuracy. I'm not familiar enough with SSH protocol to even make any guesses here... but this makes it quite difficult to complete any large transfers.


You should set your xDSL/Cable Network Card MTU Value to 1400 or 1300. It will fix your timeout problem.
martin

Re: SCP/SFTP transfers timing out

I'm sorry, but I have no experience with the problem.
runderwo

SCP/SFTP transfers timing out

Anyone know why SCP and SFTP transfers would time out every 50 megs or so and require the user to resume? It can be reproduced with fairly good accuracy. I'm not familiar enough with SSH protocol to even make any guesses here... but this makes it quite difficult to complete any large transfers.