[Info-vax] SFTP hang - from VMS to Windows

[Bob Gezelter]

On Monday, February 25, 2013 7:13:33 AM UTC-5, GerMarsh wrote:
> Anyone seen anything like this?
> 
> 
> 
> We get intermittent hangs during file transfers - nothing consistent about which file will be affected nor their sizes.
> 
> 
> 
> Windows is running an OpenText (Hummingird) server. VMS is TCPIP Services V5.6 - ECO 2.
> 
> 
> 
> The "hang" can be kicked into life by trying an FTP connection to the same server!
> 
> 
> 
> The logfile shows something like this:
> 
> sftp> ascii
> 
> 
> 
> sftp> lcd /$1$DGA22/DATA/USERS/PC_SCHEDULE
> 
> 
> 
> /$1$DGA22/data/users/pc_schedule
> 
> sftp> cd /er_pc_root
> 
> 
> 
> /ER_PC_Root
> 
> sftp> put PC_ASCII_FILE.DAT
> 
> 
> 
> PC_ASCII_FILE.DAT     |   96kB |  96.0 kB/s | ETA: 00:00:23 |   4%
> 
> PC_ASCII_FILE.DAT     |  288kB | 144.0 kB/s | ETA: 00:00:14 |  12%
> 
> PC_ASCII_FILE.DAT     |  384kB | 128.0 kB/s | ETA: 00:00:15 |  16%
> 
> PC_ASCII_FILE.DAT     |  576kB | 144.0 kB/s | ETA: 00:00:12 |  24%
> 
> PC_ASCII_FILE.DAT     |  704kB | 140.8 kB/s | ETA: 00:00:11 |  29%
> 
> PC_ASCII_FILE.DAT     |  864kB | 144.0 kB/s | ETA: 00:00:10 |  36%
> 
> PC_ASCII_FILE.DAT     |  1.1MB | 155.4 kB/s | ETA: 00:00:08 |  45%
> 
> PC_ASCII_FILE.DAT     |  1.3MB | 168.0 kB/s | ETA: 00:00:06 |  56%
> 
> PC_ASCII_FILE.DAT     |  1.5MB | 174.2 kB/s | ETA: 00:00:04 |  65%
> 
> PC_ASCII_FILE.DAT     |  1.8MB | 185.6 kB/s | ETA: 00:00:02 |  77%
> 
> PC_ASCII_FILE.DAT     |  2.1MB | 192.0 kB/s | ETA: 00:00:01 |  88%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 194.7 kB/s | ETA: 00:00:00 |  97%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 182.2 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 169.1 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 157.9 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 148.0 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 139.3 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 131.6 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 124.6 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 118.4 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 112.8 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 107.6 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB | 103.0 kB/s | ETA: 00:00:00 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB |  98.7 kB/s | ETA: 00:00:00 |  99%
> 
> .
> 
> .
> 
> .
> 
> PC_ASCII_FILE.DAT     |  2.3MB |   3.1 kB/s | ETA: 00:00:06 |  99%
> 
> PC_ASCII_FILE.DAT     |  2.3MB |   3.1 kB/s | TOC: 00:12:46 | 100%
> 
> sftp> quit
> 
> 
> 
> The transfer sits at 99% with no throughput - and the associated average rate decreasing. 
> 
> 
> 
> There is nothing significant in the logs on the Windows side but I don't think the problem lies on the VMS end either.
> 
> 
> 
> Networks support also state that there is no contention on the network during these incidents.
> 
> 
> 
> The process is not really hanging as it is dutifully outputting its progress. Just sits in LEF state most of the time. Two BG devices in use but I would expect that. No process or pooled quota issues either.
> 
> 
> 
> As ever, any pointers gratefully received!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Gerald.

Gerald,

As always, a line trace of the connection would be extremely useful.

I have seen similar situations (not just involving SFTP) when packets get lost enroute (either direction). Most commonly, this involves the infamous "duplex mismatch" somewhere in the path between the nodes.

A network trace will show the behavior characteristic of such a problem. Often, it will manifest if there is ANY other network traffic (the actual problem is a packet getting lost while something is going in the opposite direction).

In a complex network, tracing the problem can be a challenge.

- Bob Gezelter, http://www.rlgsc.com