[SOLVED] put hangs on bigger files to certain hostings
See original GitHub issueIf I am trying to upload small file colors.js
everything works like a breeze. As soon as I want to do the same with main.js
. Put hangs.
-rw-rw-r-- 1 sbtge sbtge 167 Aug 15 22:42 colors.js
-rw-rw-rw- 1 sbtge sbtge 11833 Aug 15 22:49 main.js
Here is the log.
[2021-08-15T22:49:10.698] INFO: 🔼 [SFTPClient] uploading main.js
[2021-08-15T22:49:10.698] CLIENT[sftp]: put: Adding temp event listeners
[2021-08-15T22:49:10.699] Outbound: Sending CHANNEL_DATA (r:0, 63)
[2021-08-15T22:49:10.699] SFTP: Outbound: Buffered OPEN
[2021-08-15T22:49:10.699] CLIENT[sftp]: put source is a stream
[2021-08-15T22:49:10.731] Inbound: CHANNEL_DATA (r:0, 17)
[2021-08-15T22:49:10.732] SFTP: Inbound: Received HANDLE (id:0)
[2021-08-15T22:49:10.732] Outbound: Sending CHANNEL_DATA (r:0, 25)
[2021-08-15T22:49:10.732] SFTP: Outbound: Buffered FSETSTAT
[2021-08-15T22:49:10.765] Inbound: CHANNEL_DATA (r:0, 28)
[2021-08-15T22:49:10.765] SFTP: Inbound: Received STATUS (id:1, 0, "Success")
[2021-08-15T22:49:10.766] Outbound: Sending CHANNEL_DATA (r:0, 7320)
[2021-08-15T22:49:10.766] SFTP: Outbound: Sent WRITE (id:2)
[2021-08-15T22:49:12.645] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:14.645] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:16.645] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:18.646] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:20.647] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:22.647] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:24.647] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:26.648] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:28.648] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:30.648] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:32.649] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:34.649] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:36.649] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:38.650] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:40.650] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:42.650] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:44.650] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:46.650] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:48.650] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:50.651] Outbound: Sending ping (GLOBAL_REQUEST: keepalive@openssh.com)
[2021-08-15T22:49:52.652] CLIENT[sftp]: put: Handling error: Keepalive timeout
[2021-08-15T22:49:52.652] CLIENT[sftp]: put: handled error with reject
[2021-08-15T22:49:52.652] CLIENT[sftp]: Global: Ignoring handled error
[2021-08-15T22:49:52.652] CLIENT[sftp]: put: Removing temp event listeners
[2021-08-15T22:49:52.653] Error: put: Keepalive timeout
at fmtError (/home/sbtge/workspace/1-lab/ftp-syncer/dist/index.js:3767:22)
at Client.fn (/home/sbtge/workspace/1-lab/ftp-syncer/dist/index.js:3782:20)
at Client.emit (node:events:388:22)
at Timeout.sendKA (/home/sbtge/workspace/1-lab/ftp-syncer/node_modules/ssh2/lib/client.js:662:16)
at listOnTimeout (node:internal/timers:556:17)
at processTimers (node:internal/timers:499:7)
I am using ssh2-sftp-cllient: 7.0.1
and node v. 15.3.0
.
Issue Analytics
- State:
- Created 2 years ago
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Rsync hangs on large files - Quick fixes !!
In short, the reasons where Rsync hangs on large files are insufficient RAM space on the server, bad connection, wrong SSH settings and...
Read more >SFTP: Downloading Large Files Hangs / Stalls · Issue #926
I'm using paramiko-2.1. 2 and I'm running into an issue where Paramiko appears to hang or stall when downloading a large file (in...
Read more >WebDav Large File Upload Hangs - MSDN - Microsoft
I am transferring large files (700MB and larger) from my Vista Pro x64 laptop to my Windows 7 x64 server using IIS 7...
Read more >(SOLVED) Rpi 4 large file transfer makes system hang
Hi, I have file transfer problem with my Rpi4+, 8GB, Debian buster, just upgrade Bullseye last week. This problem is same under buster...
Read more >paramiko hangs on get after ownloading 20 MB of file
Unable to figure out what the issue is. Increasing the window size did not solve either. Any help would be much appreciated! host...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks, I’ll add it to the ‘Troubleshooting’ section of the README. In the ‘old days’, it was common to have to set an MTU of 1400 whenever you needed to interact with Windows/MS-DOS based systems. I had completely forgotten that as it has been some time since I’ve seen this issue.
No idea. I wouldn’t be surprised if it wasn’t something particular to the network stack and WSL. I’d install node on native windows and see if that works.
Note that I don’t use windows. I do run the test suite on a windows 10 system and I do test against a Windows based sftp server, but I have little experience with that platform.
My money would be that it is to do with the WSL layer - this is effectively a virtual machine where they are doing some network bridging across the main host network stack and that could introduce all sorts of weirdness.
BTW I don’t think you need the put options - they are effectively the defaults anyway. Likewise with setting port as 22 is the default. In general, I think it is better not to supply options unless you need to change them from the default.