2.9p2 behaves different from 2.5.2p2 on tunneling issue

[Corinna Vinschen]

On Wed, Sep 12, 2001 at 12:42:54PM +0200, Markus Friedl wrote:
> the previous -N implementation was broken.
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.c.diff?r1=1.105&r2=1.106
> 
> On Tue, Sep 04, 2001 at 09:25:59PM +0200, Corinna Vinschen wrote:
> > This has run reliable with 2.5.2 over the last months. Now, after
> > I have upgraded to 2.9p2, the tunnel is closed right after each
> > attempt of an application to use the tunnel which is a cron job
> > running each 5 minutes. So, now the tunnel is closed and restarted
> > each 5 minutes :-(
> 
> i cannot reproduce this.
> 
> the previous behaviour was to close the connection
> after the last connection to the localhost port
> has been closed.

But that's exactly what happens now using 2.9p2 and even when
using the latest from the portable CVS tree while the connection
using 2.5.2p2 stays open all the time.

I've just tried it again using the latest from cvs started
from the command line using -v -v -v.

The command is

    ssh -2 -g -N -o 'ConnectionAttempts 3600' \
	-L 8110:pop.server.tld:110 \
	tunnel.server.tld

The debug output is:

=============================================================================
[...usual stuff when connecting...]
debug1: Connections to local port 8110 forwarded to remote address pop.server.tld:110
debug1: Local forwarding listening on 0.0.0.0 port 8110.
debug1: fd 4 setting O_NONBLOCK
debug2: fd 4 is O_NONBLOCK
debug1: channel 0: new [port listener]
debug1: Entering interactive session.
=============================================================================

At that point it waits for activity. Now I'm starting fetchmail using
port 8110 on localhost:

=============================================================================
debug1: Connection to port 8110 forwarding to pop.server.tld port 110 requested.
debug1: fd 5 setting O_NONBLOCK
debug2: fd 5 is O_NONBLOCK
debug1: channel 1: new [direct-tcpip]
debug1: channel 1: open confirm rwindow 30000 rmax 16384
debug1: channel 1: read<=0 rfd 5 len 0
debug1: channel 1: read failed
debug1: channel 1: input open -> drain
debug1: channel 1: close_read
debug1: channel 1: ibuf empty
debug1: channel 1: input drain -> closed
debug1: channel 1: send eof
debug1: channel 1: rcvd close
debug1: channel 1: output open -> drain
debug2: channel 1: no data after CLOSE
debug1: channel 1: obuf empty
debug1: channel 1: output drain -> closed
debug1: channel 1: close_write
debug1: channel 1: send close
debug1: channel 1: is dead
debug1: channel_free: channel 1: direct-tcpip: listening port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3238, nchannels 2
debug3: channel_free: status: The following connections are open:
  #1 direct-tcpip: listening port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3238 (t4 r0 i8/0 o128/0 fd 5/5)

debug3: channel_close_fds: channel 1: r 5 w 5 e -1
debug1: channel_free: channel 0: port listener, nchannels 1
debug3: channel_free: status: The following connections are open:

debug3: channel_close_fds: channel 0: r 4 w 4 e -1
Connection to tunnel.server.tld closed by remote host.
debug1: Transferred: stdin 0, stdout 0, stderr 53 bytes in 19.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.8
debug1: Exit status -1
debug1: compress outgoing: raw data 1272, compressed 736, factor 0.58
debug1: compress incoming: raw data 2845, compressed 1813, factor 0.64
prompt$
=============================================================================

That's it. The connection has been closed.


The same looks that way using 2.5.2p2:

=============================================================================
[...usual stuff when connecting...]
debug1: Connections to local port 8110 forwarded to remote address pop.server.tld:110
debug1: Local forwarding listening on 0.0.0.0 port 8110.
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: channel 0: new [port listener]
debug1: channel 1: new [client-session]
debug1: send channel open 1
debug1: Entering interactive session.
debug2: callback start
debug1: client_init id 1 arg 0
debug2: callback done
debug1: channel 1: open confirm rwindow 10000 rmax 32768
=============================================================================

At that point it waits for activity. Now I'm starting fetchmail using
port 8110 on localhost:

=============================================================================
debug1: Connection to port 8110 forwarding to pop.server.tld port 110 requested.
debug1: fd 8 setting O_NONBLOCK
debug1: fd 8 IS O_NONBLOCK
debug1: channel 2: new [listen port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3246]
debug1: channel 2: open confirm rwindow 30000 rmax 16384
debug1: channel 2: read<=0 rfd 8 len 0
debug1: channel 2: read failed
debug1: channel 2: input open -> drain
debug1: channel 2: close_read
debug1: channel 2: input: no drain shortcut
debug1: channel 2: ibuf empty
debug1: channel 2: input drain -> closed
debug1: channel 2: send eof
debug1: channel 2: rcvd close
debug1: channel 2: output open -> drain
debug2: channel 2: no data after CLOSE
debug1: channel 2: obuf empty
debug1: channel 2: output drain -> closed
debug1: channel 2: close_write
debug1: channel 2: send close
debug1: channel 2: is dead
debug1: channel_free: channel 2: status: The following connections are open:
  #1 client-session (t4 r0 i1/0 o16/0 fd 4/5)
  #2 listen port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3246 (t4 r1 i8/0 o128/0 fd 8/8)
=============================================================================

And at that point it still waits for the next connection, which is what
I have expected.

Hope that gives some hint,
Corinna