SSH -R problem

Pierre A. Humblet
Mon Apr 29 18:02:00 GMT 2002

In the thread
Steve Chew, Chris and Corinna discuss a listen()
problem with ssh -R. Here is the explanation.

1) In Windows, a connect() always creates a listen socket
with the same port number as the connect socket.
That's easy to verify, e.g. with Windows telnet.
Note that the listen socket address is 
To the contrary the Cygwin select() call creates a 
listening socket where yyy is arbitrary.

2) The reason the sockets persist is that they are 
non-blocking. On Win95/98/ME close() doesn't work 
correctly for non-blocking sockets, as reported in 

The patch in fhandler_socket::close() would be something like:
/* HACK */
If the socket is non blocking
  then make it blocking 
       set linger to Off 
         (which will make close() non-blocking, as desired)
  else set linger to On, as done currently
The WSAEWOULDBLOCK stuff could go away.

I don't have the time to test and submit a real patch for the 
moment, perhaps Steve could help.
My rough test code basically adds
 int request = 0;
 ioctl (FIONBIO, &request);
 linger.l_onoff = 0; 
I have made > 500 calls into a connection created by ssh -R 
from WinME to WinME and > 100 calls into ssh -L from a client 
on WinME to a server on Win98. 

Of course we are then exposed to the issue that Cygwin was trying
to fix by setting linger to On, i.e. the case of a process 
exiting just after the close(). Fortunately sockets are usually 
non blocking in situations where there is some kind of persistent 
daemon handling several connections (or so I hope, otherwise ???).

Also in 
I was speculating that my proposed patch to sshd would not take
care of the CLOSE_WAIT bug for ssh -R or -L.
This was unduly pessimistic. The bug does not occur in these
cases because no subprocess is forked.


More information about the Cygwin-patches mailing list