https://bugzilla.mindrot.org/show_bug.cgi?id=1917
Darren Tucker <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #10 from Darren Tucker <[email protected]> --- 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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
