Problematic issue with the x11_create_display_inet method in channel.c

[Christian Plattner]

Hi,

I am currently implementing X11 forwarding for our Java SSH2 library
(http://www.ganymed.ethz.ch/ssh2), and encountered a problem with the 
automatic display number selection
in the x11_create_display_inet() method in channel.c.

With my testcode I am able to get the OpenSSH daemon in a state where a 
following client connection, e.g., an OpenSSH client, is sometimes not 
able to properly use X11 forwarding.

I have no idea if you consider this to be relevant at all, but I would 
be very happy if one of the developers could take a look at it.

Thanks,
- Christian

============ DETAILED DESCRIPTION =====================================

Seen on: OpenSSH 4.1 on Fedora Core 4 (2.6.11-1.35_FC3smp).

Summary:

When doing X11 forwarding, OpenSSH sometimes attaches itself to a port 
(e.g., 6010) when there is still a connection to 127.0.0.1:6010 (in 
state TIME_WAIT). As a consequence, even though OpenSSH's bind operation 
to ::1:6010 goes well, X11 applications are not able to connect to 
127.0.0.1:6010.

Details:

Here is a part of netstat output if everything is fine (OpenSSH is ready 
to forward X11 connections)

Proto Recv-Q Send-Q Local Address               Foreign Address 
      State
tcp        0      0 127.0.0.1:6010              0.0.0.0:* 
     LISTEN
tcp        0      0 ::1:6010                    :::* 
     LISTEN

Here is a part of netstat output when things went wrong (OpenSSH thinks 
it is ready to forward X11 connections =)

Proto Recv-Q Send-Q Local Address               Foreign Address 
      State
tcp        0      0 127.0.0.1:6010              127.0.0.1:54806 
     TIME_WAIT
tcp        0      0 ::1:6010                    :::* 
     LISTEN

How did that happen? Well, the TIME_WAIT entry came from a previous (now 
closed) ssh connection that was using X11 forwarding, i.e., before the 
current ssh connection was opened, the netstat output looked as follows:

Proto Recv-Q Send-Q Local Address               Foreign Address 
      State
tcp        0      0 127.0.0.1:6010              127.0.0.1:54806 
     TIME_WAIT

I managed to produce such an entry by simply closing the ssh connection 
while X11 forwarding was in use (and one X11 application was active).