simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  a9e1053 Log the server's diagnostics if main channel open fails.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-06-15 19:03:48

commit a9e1053c8ae29c80cf0827c346e7dac976fb949b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=a9e1053c8ae29c80cf0827c346e7dac976fb949b;hp=f31a72ba09d20e076f62e39e0f59404511bf6c86
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jun 15 18:58:01 2017 +0100

    Log the server's diagnostics if main channel open fails.
    
    This has been a FIXME in the code for ages, because back when the main
    channel was always a pty session or a program run in a pipe, there
    weren't that many circumstances in which the actual CHANNEL_OPEN could
    return failure, so it never seemed like a priority to get round to
    pulling the error information out of the CHANNEL_OPEN_FAILURE response
    message and including it in PuTTY or Plink's local error message.
    
    However, 'plink -nc' is the real reason why this is actually
    important; if you tell the SSH server to make a direct-tcpip network
    connection as its main channel, then that can fail for all the usual
    network-unreliability reasons, and you actually do want to know which
    (did you misspell the hostname, or is the target server refusing
    connections, or has network connectivity failed?). This actually bit
    me today when I had such a network failure, and had to debug it by
    pulling that information manually out of a packet log. Time to
    eliminate that FIXME.
    
    So I've pulled the error-extracting code out of the previous handler
    for OPEN_FAILURE on non-main channels into a separate function, and
    arranged to call that function if the main channel open fails too. In
    the process I've made a couple of minor tweaks, e.g. if the server
    sends back a reason code we haven't heard of, we say _what_ that
    reason code was, and also we at least make a token effort to spot if
    we see a packet other than OPEN_{CONFIRMATION,FAILURE} reaching the
    main loop in response to the main channel-open.

 ssh.c | 61 ++++++++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 42 insertions(+), 19 deletions(-)