[Bug 1917] Escape sequence (~) doesn't work right with ControlMaster/ControlPersist connections

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1917

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #10 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2297
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2297&action=edit
allow ~. to abandon mux master channels

I think I figured this out.

When your network changes or goes away and you disconnection with ~.
ssh sends a channel close.  normally this isn't a problem because the
ssh goes away immediately thereafter.  when you do it in a mux client,
the mux client goes away but the mux master stays up.  normally that's
not a problem either, because the mux master is similarly wedged and
can be ~.'ed too.  that is, unless you also use controlpersist.

when all of these things happen together the ssh mux master, which is
backgrounded, hangs around waiting for the channel close confirmation
from the server, which isn't going to happen because, hey, the network
is
busted.  that wouldn't be a problem either except that the backgrounded
mux master won't exit until all its channels are closed, and until it
exits the controlmaster socket remains there preventing you from making
a new one.  the net result is that you can't make any new connections
until you find and kill the backgrounded mux master.

you can't just free the channel on ~. because in the case where the
network is not broken you'll get a channel close from the server for a
non-existant channel and the mux master will fatal.

what this patch does is add a new "ABANDONED" state, which is basically
the same as CLOSED or INPUT_DRAINING except it's not counted as an
active channel. the ~. sequence then sends a close on the channel and
puts it into this state.  if the server confirmation comes back the
channel is freed as per normal, but if not it's just kept around but
not used.

Please try the attached patch (it's against -current, I'll make an
equivalent one against 6.2p2).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.