OpenSSH client disconnects after 5.2 upgrade

[burley+ (Graham Burley)]

Following an upgrade to OpenVMS 8.3 and Multinet 5.2 we've been seeing
problems on DECUServe with certain ssh clients, an ssh session gets
disconnected in the middle of a large-ish output stream, .e.g. a
DIR/FULL or a SHO LOG * or just TYPing a large file.

SSH-031_A052 & UCX_LIBRARY_EMULATION-070_A052 are installed.

Clients effected:
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006 on Mac OS X
OpenSSH_4.3p2 Debian-8ubuntu1.1, OpenSSL 0.9.8c 05 Sep 2006

These clients didn't have problems before the upgrade.

[Dan O'Reilly]

We've had 1 report of this that I'm still tracking down. It would be of
great help if you could have debug level 6 turned on for a time when you
can capture a session or two that disconnects like this. Note this could
suck up some disk space if you get huge amounts of activity.

Post by burley+ (Graham Burley)
Following an upgrade to OpenVMS 8.3 and Multinet 5.2 we've been seeing
problems on DECUServe with certain ssh clients, an ssh session gets
disconnected in the middle of a large-ish output stream, .e.g. a
DIR/FULL or a SHO LOG * or just TYPing a large file.
SSH-031_A052 & UCX_LIBRARY_EMULATION-070_A052 are installed.
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006 on Mac OS X
OpenSSH_4.3p2 Debian-8ubuntu1.1, OpenSSL 0.9.8c 05 Sep 2006
These clients didn't have problems before the upgrade.

------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+

[V***@SendSpamHere.ORG]

Post by Dan O'Reilly
We've had 1 report of this that I'm still tracking down. It would be of
great help if you could have debug level 6 turned on for a time when you
can capture a session or two that disconnects like this. Note this could
suck up some disk space if you get huge amounts of activity.

Dan, I've experienced this from my Powerbook when sshing into Eisner.

Is there any debugging info from the client side that would be helpful
in addition to the debugging on the server side?

[burley+ (Graham Burley)]

Post by Dan O'Reilly
We've had 1 report of this that I'm still tracking down. It would be of
great help if you could have debug level 6 turned on for a time when you
can capture a session or two that disconnects like this. Note this could
suck up some disk space if you get huge amounts of activity.

Does this help? If you need more I have copies of the log files.

debug[00013C60]: (17:01:43)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 272 bytes
debug[00013C60]: (17:01:43)Ssh2Transport/TRCOMMON.C;3:572: Outgoing empty, sending empty ignore packet.
debug[00013C60]: (17:01:43)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 928 bytes
debug[00013C60]: (17:01:43)Ssh2Transport/TRCOMMON.C;3:612: Disconnecting: reason code: 10 message: 'Connection lost on output.'
debug[00013C60]: (17:01:43)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 928 bytes
debug[00013C60]: (17:01:43)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT received: Connection lost on output.
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:329: locally_generated = TRUE
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:467: Ready to die
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:472: Status from deaccess 1E0, status = 1 iosb 1
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:474: Status from dassgn 1E0, status = 1

debug[0001725B]: (17:00:53)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1264 bytes
debug[0001725B]: (17:00:53)Pty-VMS/PTY-VMS.C;1:434: read ast: status 1 bytes 2 buffered 918 remain 106
debug[0001725B]: (17:00:53)Pty-VMS/PTY-VMS.C;1:434: read ast: status 1 bytes 64 buffered 920 remain 104
debug[0001725B]: (17:00:53)Ssh2Transport/TRCOMMON.C;3:612: Disconnecting: reason code: 10 message: 'Connection lost on output.'
debug[0001725B]: (17:00:53)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1264 bytes
debug[0001725B]: (17:00:53)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT received: Connection lost on output.
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:329: locally_generated = TRUE
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:467: Ready to die
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:472: Status from deaccess 1E0, status = 1 iosb 1
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:474: Status from dassgn 1E0, status = 1

debug[0001F849]: (17:00:33)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1264 bytes
debug[0001F849]: (17:00:33)Ssh2Transport/TRCOMMON.C;3:572: Outgoing empty, sending empty ignore packet.
debug[0001F849]: (17:00:33)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1296 bytes
debug[0001F849]: (17:00:33)Ssh2Transport/TRCOMMON.C;3:612: Disconnecting: reason code: 10 message: 'Connection lost on output.'
debug[0001F849]: (17:00:33)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1296 bytes
debug[0001F849]: (17:00:33)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT received: Connection lost on output.
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:329: locally_generated = TRUE
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:467: Ready to die
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:472: Status from deaccess 1E0, status = 1 iosb 1
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:474: Status from dassgn 1E0, status = 1

[burley+ (Graham Burley)]

[snip]

Oops, forgot to say that with debug level 6 on ssh was slower ... !
but seriously, the problem was more difficult to reproduce, it took
3 or 4 repetitions of DIR/FUL to generate a disconnect.

[Dan O'Reilly]

These are indicating the client disconnected for some reason. Can you get
client debug that corresponds to this error?

Post by burley+ (Graham Burley)

Post by Dan O'Reilly
We've had 1 report of this that I'm still tracking down. It would be of
great help if you could have debug level 6 turned on for a time when you
can capture a session or two that disconnects like this. Note this could
suck up some disk space if you get huge amounts of activity.

Does this help? If you need more I have copies of the log files.
debug[00013C60]: (17:01:43)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 272 bytes
debug[00013C60]: (17:01:43)Ssh2Transport/TRCOMMON.C;3:572: Outgoing empty,
sending empty ignore packet.
debug[00013C60]: (17:01:43)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 928 bytes
reason code: 10 message: 'Connection lost on output.'
debug[00013C60]: (17:01:43)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 928 bytes
debug[00013C60]: (17:01:43)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT
received: Connection lost on output.
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:329: locally_generated = TRUE
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:467: Ready to die
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:472: Status from deaccess 1E0, status = 1 iosb 1
debug[00013C60]: (17:01:43)Sshd2/SSHD2.C;2:474: Status from dassgn 1E0, status = 1
debug[0001725B]: (17:00:53)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1264 bytes
debug[0001725B]: (17:00:53)Pty-VMS/PTY-VMS.C;1:434: read ast: status
1 bytes 2 buffered 918 remain 106
debug[0001725B]: (17:00:53)Pty-VMS/PTY-VMS.C;1:434: read ast: status
1 bytes 64 buffered 920 remain 104
reason code: 10 message: 'Connection lost on output.'
debug[0001725B]: (17:00:53)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1264 bytes
debug[0001725B]: (17:00:53)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT
received: Connection lost on output.
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:329: locally_generated = TRUE
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:467: Ready to die
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:472: Status from deaccess 1E0, status = 1 iosb 1
debug[0001725B]: (17:00:53)Sshd2/SSHD2.C;2:474: Status from dassgn 1E0, status = 1
debug[0001F849]: (17:00:33)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1264 bytes
debug[0001F849]: (17:00:33)Ssh2Transport/TRCOMMON.C;3:572: Outgoing empty,
sending empty ignore packet.
debug[0001F849]: (17:00:33)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1296 bytes
reason code: 10 message: 'Connection lost on output.'
debug[0001F849]: (17:00:33)SshUnixFdStream/SSHUNIXFDSTREAM.C;1:308: writing 1296 bytes
debug[0001F849]: (17:00:33)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT
received: Connection lost on output.
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:329: locally_generated = TRUE
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:467: Ready to die
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:472: Status from deaccess 1E0, status = 1 iosb 1
debug[0001F849]: (17:00:33)Sshd2/SSHD2.C;2:474: Status from dassgn 1E0, status = 1

------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+

[Graham Burley]

Post by Dan O'Reilly
These are indicating the client disconnected for some reason. Can you get
client debug that corresponds to this error?

There doesn't seem to be much consistency, but corrupted MAC and bad
packet length have both been reported as errors as seen here. These
are from 4 session disconnects just now, they don't correspond to the
Multinet logs previously posted.

$ tail -n 10 s*.log
==> s1.log <==
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 262144 rmax 16384
Disconnecting: Corrupted MAC on input.
debug3: channel 0: close_fds r 4 w 5 e 6 c -1

==> s2.log <==
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 262144 rmax 16384
debug2: channel 0: window 32193 sent adjust 33343
Disconnecting: Bad packet length 1154421961.
debug3: channel 0: close_fds r 4 w 5 e 6 c -1

==> s3.log <==
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)

debug3: channel 0: close_fds r 4 w 5 e 6 c -1
debug1: fd 2 clearing O_NONBLOCK
Connection to eisner.encompasserve.org closed by remote host.
Connection to eisner.encompasserve.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 111 bytes in 35.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3.1
debug1: Exit status -1

==> s4.log <==
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)

debug3: channel 0: close_fds r 4 w 5 e 6 c -1
debug1: fd 2 clearing O_NONBLOCK
Connection to eisner.encompasserve.org closed by remote host.
Connection to eisner.encompasserve.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 111 bytes in 7.8 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 14.3
debug1: Exit status -1

[burley+ (Graham Burley)]

Post by Dan O'Reilly
These are indicating the client disconnected for some reason. Can you get
client debug that corresponds to this error?

There doesn't seem to be much consistency, but corrupted MAC and bad
packet length have both been reported as errors as seen here. These
are from 4 session disconnects just now, they don't correspond to the
Multinet logs previously posted.

$ tail -n 10 s*.log
==> s1.log <==
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 262144 rmax 16384
Disconnecting: Corrupted MAC on input.
debug3: channel 0: close_fds r 4 w 5 e 6 c -1

==> s2.log <==
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 262144 rmax 16384
debug2: channel 0: window 32193 sent adjust 33343
Disconnecting: Bad packet length 1154421961.
debug3: channel 0: close_fds r 4 w 5 e 6 c -1

==> s3.log <==
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)

debug3: channel 0: close_fds r 4 w 5 e 6 c -1
debug1: fd 2 clearing O_NONBLOCK
Connection to eisner.encompasserve.org closed by remote host.
Connection to eisner.encompasserve.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 111 bytes in 35.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3.1
debug1: Exit status -1

==> s4.log <==
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)

debug3: channel 0: close_fds r 4 w 5 e 6 c -1
debug1: fd 2 clearing O_NONBLOCK
Connection to eisner.encompasserve.org closed by remote host.
Connection to eisner.encompasserve.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 111 bytes in 7.8 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 14.3
debug1: Exit status -1

[Dan O'Reilly]

Try installing the UCX_LIBRARY_EMULATION_072-A052 ECO. What you're seeing
(the MAC errors etc) should be corrected by this.

Post by Graham Burley

Post by Dan O'Reilly
These are indicating the client disconnected for some reason. Can you get
client debug that corresponds to this error?

There doesn't seem to be much consistency, but corrupted MAC and bad
packet length have both been reported as errors as seen here. These
are from 4 session disconnects just now, they don't correspond to the
Multinet logs previously posted.
$ tail -n 10 s*.log
==> s1.log <==
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 262144 rmax 16384
Disconnecting: Corrupted MAC on input.
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
==> s2.log <==
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 262144 rmax 16384
debug2: channel 0: window 32193 sent adjust 33343
Disconnecting: Bad packet length 1154421961.
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
==> s3.log <==
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
debug1: fd 2 clearing O_NONBLOCK
Connection to eisner.encompasserve.org closed by remote host.
Connection to eisner.encompasserve.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 111 bytes in 35.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3.1
debug1: Exit status -1
==> s4.log <==
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
debug1: fd 2 clearing O_NONBLOCK
Connection to eisner.encompasserve.org closed by remote host.
Connection to eisner.encompasserve.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 111 bytes in 7.8 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 14.3
debug1: Exit status -1

------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+

[Jim]

Post by Dan O'Reilly
Try installing the UCX_LIBRARY_EMULATION_072-A052 ECO.

With that particular UCX patch installed on an IA64 system running
MultiNet 5.2 I am able to replicate Graham's problem when the client
system is an AlphaServer running VMS and MultiNet 5.2 - control is
returned to the AlphaServer. Since installing MultiNet 5.2 on this
IA64 system any attempt to display a lengthy data stream ($ type sys
$startup:*.com ! for example) results in an aborted SSH connection.
This behavior has been consistent independent of the SSH client used.
It also occurs when an AlphaServer is used on the server side and runs
MultiNet 5.2. FWIW, failures occur quicker on IA64 than Alpha and also
quicker when the server is not performing any debug logging. Also,
during my testing, servers were alway running VMS 8.3 along with
MultiNet 5.2.

[Dan O'Reilly]

Can you get client debug? I would like to see why the client thinks it
needs to disconnect.

Post by Jim

Post by Dan O'Reilly
Try installing the UCX_LIBRARY_EMULATION_072-A052 ECO.

With that particular UCX patch installed on an IA64 system running
MultiNet 5.2 I am able to replicate Graham's problem when the client
system is an AlphaServer running VMS and MultiNet 5.2 - control is
returned to the AlphaServer. Since installing MultiNet 5.2 on this
IA64 system any attempt to display a lengthy data stream ($ type sys
$startup:*.com ! for example) results in an aborted SSH connection.
This behavior has been consistent independent of the SSH client used.
It also occurs when an AlphaServer is used on the server side and runs
MultiNet 5.2. FWIW, failures occur quicker on IA64 than Alpha and also
quicker when the server is not performing any debug logging. Also,
during my testing, servers were alway running VMS 8.3 along with
MultiNet 5.2.

------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+

[Jim]

Can you get client debug?  I would like to see why the client thinks it
needs to disconnect.

This is the tail end of the debug=6 output from the client side when
the client is an AlphaServer running VMS 7.3-2 and MultiNet 5.2
connecting to an IA64 server running VMS 8.3 and MultiNet 5.2 when the
command "$ type sys$startup:*.com" was executed. The lines beginning
with dollar signs and ending in hyphens are the content of the command
files that were being displayed. As I mentioned previously, it takes
much longer to fail when debug is active - both in duration and the
amount of data that is transferred. (Could be a flow control or timing
issue of some sort perhaps?)

debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
19 bytes
$if .not. $status
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
7 bytes
$then
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
90 bytes
$config_fail = "-TCPIP-E-DIRNOTCRE, ''dir_file' directory file not
created"
$goto error
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
77 bytes
$endif
$define /user_mode sys$output nl:
$define /user_mode sys$error nl:
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
38 bytes
$set security 'dir_file' -
/acl=( -
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
63 bytes
(identifier=anonymous, -
access=read+write+execute+delete, -
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
23 bytes
options=protected), -
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
26 bytes
(identifier=anonymous, -
access=read+write+execute+delete, -
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
23 bytes
options=protected), -
debug: (08:14:43)SshSubSystemFdStream/SSHUNIXFDSTREAM.C;1:308: writing
26 bytes
(identifier=anonymous, -
debug: (08:14:43)Ssh2Common/SSHCOMMON.C;1:98: DISCONNECT received:
Message auth.
debug: (08:14:43)Ssh2/SSH2.C;1:215: locally_generated = TRUE
Disconnected; MAC error (Message authentication check fails.).
debug: (08:14:43)Ssh2Client/SSHCLIENT.C;2:1649: Destroying client.
debug: (08:14:43)SshConfig/SSHCONFIG.C;1:2612: Freeing pki. (host_pki !
= NULL, )
debug: (08:14:43)SshCertCMi/CMI.C;1:768: Free certificate manager.
debug: (08:14:43)SshCertDB/CERT-DB.C;1:729: free'ing cert-db
debug: (08:14:43)SshCertDB/CERT-DB.C;1:769: memory left 0
debug: (08:14:43)SshCertEdb/CMI-EDB.C;1:258: EDB: Freeing databases.
debug: (08:14:44)SshCertEdbHttp/CMI-HTTP.C;1:363: Freeing HTTP
debug: (08:14:44)SshCertEdbLdap/CMI-LDAP.C;1:933: Freeing LDAP
debug: (08:14:44)SshCertEdbOcsp/CMI-OCSP.C;1:1835: Freeing OCSP.
debug: (08:14:44)SshCertEdbOcsp/CMI-OCSP.C;1:1803: Stopping OCSP
debug: (08:14:44)SshCertCMi/CMI-CONFIG.C;1:150: Free configuration.
debug: (08:14:44)Ssh2Common/SSHCOMMON.C;1:585: Destroying SshCommon
object.
debug: (08:14:44)Ssh2Common/SSHCOMMON.C;1:606: Calling clean-up hooks.
debug: (08:14:44)SshConnection/SSHCONN.C;1:2027: Destroying SshConn
object.
debug: (08:14:44)Ssh2ChannelSession/SSHCHSESSION.C;1:111: destroying
session chl
debug: (08:14:44)Ssh2Common/SSHCOMMON.C;1:696: type_contexts is
already destroy.
debug: (08:14:44)Ssh2Common/SSHCOMMON.C;1:696: type_contexts is
already destroy.
debug: (08:14:44)Ssh2Common/SSHCOMMON.C;1:719: num_channels now 0
debug: Got session close with exit_status=0
debug: (08:14:44)Ssh2/SSH2.C;1:610: destroying client struct...
debug: Input channel closed
Connection to howard closed.
debug: (08:14:44)SshFilterStream/SSHFILTERSTREAM.C;1:156: Scheduling
ssh_stream_
filter_read_upcall timeout
debug: (08:14:44)SshEventLoop/SSHUNIXELOOP.C;1:301: Uninitialized the
event loop
.
debug: (08:14:44)RSITCommon/RSIT-COMMON.C;1:158: Freeing global
SshRegex context
.
debug: (08:14:44)SshConfig/SSHCONFIG.C;1:2612: Freeing pki. (host_pki
= NULL, us
er_pki = NULL)
$

[Jim]

Post by Jim

Can you get client debug?  I would like to see why the client thinks it
needs to disconnect.

This is the tail end of the debug=6 output from the client side when
the client is an AlphaServer running VMS 7.3-2 and MultiNet 5.2
connecting to an IA64 server running VMS 8.3 and MultiNet 5.2 when the
command "$ type sys$startup:*.com" was executed.

A bit more info - I can only reproduce this failure on systems running
the combination of VMS 8.3 (either Alpha or IA64) and MultiNet 5.2.
(Alpha) systems running the combination of MultiNet 5.2 and VMS 7.3-2
do not seem to be affected. Systems running prior versions of MultiNet
also seem unaffected.

[V***@SendSpamHere.ORG]

Post by Jim

Can you get client debug? =A0I would like to see why the client thinks i=

t

needs to disconnect.

This is the tail end of the debug=3D6 output from the client side when
the client is an AlphaServer running VMS 7.3-2 and MultiNet 5.2
connecting to an IA64 server running VMS 8.3 and MultiNet 5.2 when the
command "$ type sys$startup:*.com" was executed.

A bit more info - I can only reproduce this failure on systems running
the combination of VMS 8.3 (either Alpha or IA64) and MultiNet 5.2.
(Alpha) systems running the combination of MultiNet 5.2 and VMS 7.3-2
do not seem to be affected. Systems running prior versions of MultiNet
also seem unaffected.

Jim, I was recently bitten by a bug in the CRTL. I wonder what would
happen if you installed VMS83A_CTRL_V0400 patch.

[Jim]

Post by Jim

Can you get client debug? =A0I would like to see why the client thinks i=

t

needs to disconnect.

This is the tail end of the debug=3D6 output from the client side when
the client is an AlphaServer running VMS 7.3-2 and MultiNet 5.2
connecting to an IA64 server running VMS 8.3 and MultiNet 5.2 when the
command "$ type sys$startup:*.com" was executed.

A bit more info - I can only reproduce this failure on systems running
the combination of VMS 8.3 (either Alpha or IA64) and MultiNet 5.2.
(Alpha) systems running the combination of MultiNet 5.2 and VMS 7.3-2
do not seem to be affected. Systems running prior versions of MultiNet
also seem unaffected.

Jim, I was recently bitten by a bug in the CRTL.  I wonder what would
happen if you installed VMS83A_CTRL_V0400 patch.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM

I followed that saga on comp.os.vms; and it did dawn on me that it
could be this or something like it, as the problem seems dependent on
the version of VMS. Unfortunately, that ECO has already been applied
to the SSH server side.

$ pipe prod show history | sear sys$pipe crtl
HP I64VMS VMS83I_ACRTL V4.0 Patch Install Val 19-
DEC-2007

[Kattalia, Mark]

Has anyone looked at the MTU on these systems? Do they interface through a
fiber connection or something like that? I've noticed turning off ICMP in
the firewall causes some connections to be disconnected.

This is a common problem when connecting via VPN and then not allowing the
client local network access.


Mark Kattalia
CALLAN ASSOCIATES Inc.
101 California St. Suite 3500
San Francisco, Ca. 94111
***@callan.com


-----Original Message-----
From: Jim [mailto:***@saic.com]
Sent: Wednesday, January 23, 2008 10:03 AM
To: info-***@process.com
Subject: Re: OpenSSH client disconnects after 5.2 upgrade

Post by Jim

Can you get client debug?  I would like to see why the client thinks
it needs to disconnect.

This is the tail end of the debug=6 output from the client side when
the client is an AlphaServer running VMS 7.3-2 and MultiNet 5.2
connecting to an IA64 server running VMS 8.3 and MultiNet 5.2 when the
command "$ type sys$startup:*.com" was executed.

A bit more info - I can only reproduce this failure on systems running the
combination of VMS 8.3 (either Alpha or IA64) and MultiNet 5.2.
(Alpha) systems running the combination of MultiNet 5.2 and VMS 7.3-2 do not
seem to be affected. Systems running prior versions of MultiNet also seem
unaffected.

[Jim]

Post by Kattalia, Mark
Has anyone looked at the MTU on these systems? Do they interface through a
fiber connection or something like that? I've noticed turning off ICMP in
the firewall causes some connections to be disconnected.
This is a common problem when connecting via VPN and then not allowing the
client local network access.

I haven't looked at this, however, I can think of several reasons why
I don't believe anything like this is at the root of the problem -
I'll offer one reason up. The same systems, with the same networks,
did not exhibit this behavior running prior versions of VMS and
MultiNet.

[V***@SendSpamHere.ORG]

Post by Jim

Has anyone looked at the MTU on these systems? Do they interface through a=
fiber connection or something like that? I've noticed turning off ICMP in
the firewall causes some connections to be disconnected.
This is a common problem when connecting via VPN and then not allowing the=
client local network access.

I haven't looked at this, however, I can think of several reasons why
I don't believe anything like this is at the root of the problem -
I'll offer one reason up. The same systems, with the same networks,
did not exhibit this behavior running prior versions of VMS and
MultiNet.

... I'll add that there is also no problem with my OS X ssh sessions into
machines running VMS V8.3 and TCP/IP Services ssh server.