Channel life span

[Peter Stuge]

Hi,

David Goulet wrote:
> $ ssh -L8080:<some-ip>:8181 ...
> 
> I noticed that when a third client

What are the other two clients you refer to?

What is this third client you are refering to?

What protocols are being used? 8080 is usually HTTP.

On IRC yesterday you told me that you use SSH inside the tunnel.


> send data to the local port (8080) used for forwarding, a channel
> is created:

"send data" is not so accurate. When you start ssh with -L, the
client will socket() bind() listen() and accept() on port 8080 on the
system where the client runs.

When a program later does socket() and connect() to port 8080 where
the ssh client is listening, *then* the ssh client tells the sshd it
has logged into that the client side wants to open a direct-tcpip
channel, and to where. The sshd then does socket() and connect() and
then passes data between wherever it connected to, and the channel.
I find that this is very clearly described in the SSH RFC that covers
port forwarding. I urge you to read it.


> the request then pass through the tunnel,

What type of request?


> reply comes back

What type of reply?

A complete understanding of the protocol you use inside the tunnel is
required for port forwarding over SSH just like it is for any other
network transport.


> and then the channel receives an EOF

Also not so accurate, "the channel" can not receive anything, it is
important to clearly understand what happens where, and why. Is this
EOF received by the ssh client or the sshd?


> So, I did try, using a third part lib for SSH (libssh2), to recreate
> a direct-tcpip channel and *keep* the channel open (not sending the
> EOF) in order to send data later on (where the time between writes
> on the channel is unknown). However, here is what's happening.
> After the first write to the channel, I read the data back (reply),

You must clearly say what you are communicating over the channel in
order to get any help.


> and keep the channel open (don't send the EOF on my side).

What is your side?

What are you communicating?

What is your idea of "the EOF"?
I mean: How would you "send the EOF" if you wanted to?


> A quick 5 seconds later, I get this on the sshd (server side):
> 
> debug2: channel 1: read<=0 rfd 8 len 0
> debug2: channel 1: read failed

I find this completely clear. I'm glad you also provided the
information that this happens on the server side.

So you already know that the sshd has connect() somewhere and is
constantly transferring data between that somewhere and the channel.

Here the sshd tells you that on the outgoing TCP connection that it
opened on behalf of channel 1, the read() system call returned <= 0,
which means that either there is a local OS error or that the other
end of this TCP connection made by sshd has closed the connection.


> debug2: channel 1: send eof

And thus sshd notifies the ssh client that there will be no more data
on this channel.


> and the channel is *not* usable again for transmission...

Obviously not, the TCP connection from sshd that was used to deliver
data received by sshd in the channel has been closed, so how would
you use the channel anymore?


> I did look at the openssh code to understand that behavior since
> it's not define in the RFC 4254 that it should "close" after a
> timeout.

There is no timeout involved. As I tried to explain to you already
yesterday the behavior you are seeing depends completely on the
server you are talking to and the protocol that you are using.


//Peter