ssh client stays connected after remote forward fails to bind

[Darryl L. Miles]

My command line looks like this:

ssh -2 -C -o BatchMode=yes -o KeepAlive=yes -o ServerAliveInterval=600 
-N -T -x -a -R2401:127.0.0.1:2401 <host>

I've tried to instruct SSH that the only purpose it has in life is to 
provide remote port forwarding (hence the -N -T) but if the remote fails 
to bind I get an error locally (Could not bind to remove address) and 
the SSH connection stays open and the client running.  I think the ssh 
client should terminate at this point as there is no other channel open 
nor any possibility of a channel being opened (say through dynamic port 
forwarding).

Maybe this is user error on my part ?  Would this be considered a bug or 
a feature ?  I'm using OpenSSH_3.9p1 in the client I've just investigated.

The scenario that causes this problem is that my previous ssh client 
remote port forward is still active at the remote end, due to a half 
open connection (my end was rebooted, but the remote end is still open), 
so the TCP port is still bound and in use by the remote end, but its 
only a matter of time before ServerAliveInterval=600 kicks in and kills 
that connection.  So my new ssh client instance reconnects and quickly 
sees the failure to setup remote port forward it then just stays 
connected (doing keep alives I guess) but with no useful purpose.


I am thinking that the ssh client could be better by implementing:

* Exit after the initial round of channel setups if they all fail 
because there was no further work to do once the remote bind failed is 
reported back.  This should be the default IMHO with an option to disable.

* In the case there is another channel open (multiple forwards 
multiplexed) then there should be a background timer which will 
reattempt to execute the command line / configured port forwards that 
are not currently available/active.  This background timer should be 
configurable in seconds in an option, I think the default should be 60 
seconds or so, I can't think use case that would want the default to be 
never (as it behaves right now, i.e. if you configured a forward and the 
ssh client is still running then we can presume you want that port 
forward to be setup ASAP, not a one shot attempt at startup that has 
little practical use that I can see).


Thanks for reading,

Darryl