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

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Mon Feb 25 07:46:07 EST 2013


On 2013-02-25 12:13:33 +0000, GerMarsh said:

> Anyone seen anything like this?

Weird networking glitches in organizations big enough to have "network 
support"?   All the time...

> 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.

Try some other box and configuration as the client.  Verify it's not 
something specific to the Windows box.

Basic network troubleshooting — if you're not sure of what's going on, 
start swapping some parts, and see where Mr Murphy relocates himself 
to, or if he pretends to flee.

> VMS is TCPIP Services V5.6 - ECO 2.

TCP/IP Services V5.6 ECO 2 is pretty old, too.  ECO 5 with some add-ons 
was current, when last I checked.

Check with HP, as there have been some sftp bugs (with some discussions 
here), and there may be additional updates beyond what's been released 
with ECO 5 and its ECO friends.

> The "hang" can be kicked into life by trying an FTP connection to the 
> same server!

That's slightly ambiguous: I'm going to infer you meant that starting 
up an ftp causes an existing sftp session to resume, rather than 
starting an ftp session causes a parallel sftp session to get stuck.

> 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     |  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.

*Never* believe what the networks support group tells you.  They mean 
well and they're usually a good bunch, but the gear they're probably 
using is from Cisco and the user interfaces on some of that Cisco gear 
were designed by Mr Murphy himself.

> 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!

Verify what you're told by your networking folks against what the VMS 
network counters (via LANCP and SDA) are indicating, and run your own 
tests (vlans and IP routers were invented by Mr Murphy, after all), and 
definitely check the duplex settings on the OpenVMS server.   If you 
have anything less than GbE, you may want to experiment with locking 
settings on both ends of the connection.

Also check the VMS error logs, on the unlikely chance there's something 
weird in the FC SAN or elsewhere.  Did you know Mr Murphy invented the 
SAN, too?



-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list