[Bug 790] Connection stall when client output fails and server has a lot more to send

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=790

           Summary: Connection stall when client output fails and server has
                    a lot more to send
           Product: Portable OpenSSH
           Version: 3.7.1p1
          Platform: All
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P3
         Component: ssh
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: dillon at apollo.backplane.com


Demonstrated by:  limit filesize 64k; ssh remotebox -n cat /usr/share/dict/words
| cat > junkfile.  When the write fails due to the file size limit being
reached, the client side properly closes the connection output.  However, the
server side continues to send data which the client now ignores.  This causes
the client to stop sending window updates to the server.  If the server has a
sufficient amount of data still to send it will exhaust its window and stalls
indefinitely.

The solution is to adjust the case in channel_input_data() in channels.c.  When
it  tests c->ostate != CHAN_OUTPUT_OPEN, instead of just returning we 'fake' the
consumption of the data by moving the packet_get_string() call to above the
conditional and then subtracting data_len from c->local_window and adding
data_len to c->local_consumed, then doing the appropriate xfree(data) and return;

There may be other cases where window updates could stall a connection as well,
but this one has plagued me for ages.  It can also occur when the client is
pipeing its output to a pipe which then fails (because the ssh client sets
SIGPIPE to ignore in order to process error returns). 

I can email my (possibly incomplete) patch on request, but I'm afraid I've hit
my bugzilla endurance limit.  Wish there were just an email address to send
informal bug reports to :-(.  In anycase, I think there is sufficient info above
to reproduce and fix the bug.

-Matt



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.