2.9p2 behaves different from 2.5.2p2 on tunneling issue

[Markus Friedl]

is the server running 2.9, too?

On Wed, Sep 12, 2001 at 01:37:40PM +0200, Corinna Vinschen wrote:
> 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