On 09.04.19 10:03, Tilo Eckert wrote: > Am 08.04.2019 um 20:54 schrieb g4-l...@tonarchiv.ch: >>> I'm using connectors for a direct-tcp client. So this creates two >>> connectors FD in --> channel out and vice versa. >>> >>> Now when the socket forwarding peer (not the ssh server) closes the >>> connection, i.e. reading on the socket returns 0 = EOF, we end up in >>> some loop with sending EOFs on the channel, until finally the client >>> receives a channel close message. >>> >> I attached some test code to reproduce this. >> >> Edit line 14 to your needs. It should connect to a service which does >> not dicsonnecet the connenction from its side. I.e. SSH is fine. A >> webserver will not do because it disconnects after answering the request. >> >> Start a local sshd with >> >> shell1> /usr/sbin/sshd -d -d -p 2222 >> >> shell2> ./fwconnector username localhost 2222 >> >> shell3> ssh admin@localhost -p 2022 >> Welcome to Debian... >> ~: exit >> >> On shell1 you will see the > 20 lines of "channel 0: rcvd eof" > Your callback sends an EOF for every received EOF from the server. If > your server does the same, you end up with EOF ping pong. You might want > to check whether you already sent it before: channel->local_eof != 0 > > Btw, if you close the channel on your end, an EOF is sent automatically > if one has not been sent, yet.
Hi Tilo, this is what my patch is doing: Checking for channel->local_eof != 0. But it's also an issue to poll on a socket which has EOF from the peer's side...
