openssh bugs - Jun 2013 - [Bug 1917] Escape sequence (~) doesn't work right with ControlMaster/ControlPersist connections

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.

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2076

-- 
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.

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

--- Comment #11 from Darren Tucker <dtucker at zip.com.au> ---
Created attachment 2298
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2298&action=edit
allow ~. to abandon mux master channels, diff vs 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.

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

--- Comment #12 from Darren Tucker <dtucker at zip.com.au> ---
BTW, steps to reproduce:
1) start the master with controlpersist and wait for it to log in.
2) start the slave.
3) disconnect your network.
4) in one session. type some keystrokes then quit it with ~.
5) do the same in the other
6) profit!

I put a lot of wear and tear on my laptop's ethernet port working on
this...

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2298|                            |ok+
              Flags|                            |

-- 
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.

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Darren Tucker <dtucker at zip.com.au> ---
Thanks.  Patch applied, it will be in 6.3.

-- 
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.