[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