RE: Info on "Can't open display"

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Christopher Landrieu [mailto:landrieu@hotmail.com]
> Sent: Thursday, June 14, 2001 3:19 PM
> To: cygwin-xfree@cygwin.com
> Subject: RE: Info on "Can't open display"
> 
> 
> Ok... I've done some testing and have some more info on this 
> problem.  I 
> would have more info, and would have posted it sooner, except 
> my win2k 
> installation crashed really hard (completely trashed 
> registry) over the 
> weekend (not in any way due to Cygwin or xfree86).
> 
> First, as has been discussed previously on this list, and as 
> many of you 
> kindly suggested in response to my original post, this 
> problem IS related to 
> a VPN package that I have installed.  I have Aventail Connect 
> 3.21 installed 
> on both machines.  I found that I can get local xclients to 
> work by tweaking 
> the Aventail Connect configuration file to exclude those programs 
> explicitly.  It is _alot_ of work, however, to put all of the 
> xfree86 client 
> apps in this list.
> 
> The interesting thing that I noticed with this is that it is 
> not enough to 
> simply shutdown the Aventail Connect software.  This usually 
> disables all 
> redirections of network traffic.  In this case, I found that 
> tweaking the 
> config file is the only solution.
> 
> Now, I would be satisfied to assume that this is an Aventail 
> Connect bug, 
> BUT... I am not convinced that that is the case.  Here is my 
> reasoning:
> 
>    - Aventail Connect does not have any affect on non-xfree86 
> local xclients 
> (TeraTermSSH for example).  Therefore, it IS possible to write local 
> xclients that are not impaired by the VPN software.

Do you have any other examples? TeraTermSSH is not an X client. It is an
SSH client, operates on a single well known port.
 
>    - Aventail Connect does not screw up local TCP/IP traffic 
> to server 
> processes running on localhost.  I tested this by running 
> Apache Jakarta's 
> Tomcat 4.0 Beta 1 JSP/Servlet engine on localhost port 8080.  
> This should be 
> equivalent to xfree86 running on localhost at port 6000.  I 
> am able to 
> access JSPs, servlets, and HTML pages at 
> http://localhost:8080 with a local 
> web browser with no problems at all.

Are the requests being made from
a) an unbound local port,
b) a local port bound to 127.0.0.1 port ? or
c) a local port bound to _the ethernet card/modem_ ip address

These three things will appear different to Aventail Connect, and it may
treat them differently.
This will have bearing on the feasability of changing XFree86 to work
around your problem.
Also, for d,e and f the same question applies to the listening server,
is it bound, unbound and if bound to what address.
 
>    - Aventail Connect prevents local xfree86 xclients from 
> displaying on 
> _remote_ X servers.  Yet, no other client TCP/IP programs are 
> affected 
> (telnet, ssh, ftp, etc. - to the same remote host... so 
> networking is fine).

Same two questions as before (local unbound vs local bound 127.0.0.1 vs
lcoal bound to wire)
 
>    - No other applications other than xfree86 xclients are 
> affected by the 
> Aventail Connect software.  Even other cygwin programs, which 
> I expect to 
> use the same networking APIs and features, are _not_ impared 
> by the VPN 
> software.

Thats good to know.
 
>    - The TCP/IP part of it is working.  I found this by 
> sniffing packets 
> between my win2k machine and a linux box using ethereal.  I ran 
> Cygwin/xfree86's xterm on win2k with the display set to the 
> linux boxes' 
> display (with "xhost +" on the linux box).  I did this with 
> and with out the 
> Aventail Connect config file tweak (so it was successful for 
> one try and 
> failed on the other).  What I found was that the TCP socket 
> is successfully 
> establed in both cases.  But, in the case where the the tweak was not 
> applied (the failed X connect), the win2k machine closed the 
> connection 
> immediately after openning it.  In fact it sent two 
> acknowledgements to the 
> linux boxes' SYN/ACK packet.  The first acknowledgement was 
> simply just an 
> acknowledgement (no other TCP flags set).  The second packet 
> had both ACK 
> and FIN set.  Both packets sent the exact same TCP sequence 
> numbers and 
> acknowledgement numbers (without a "next sequence number").

That sounds to me like Aventail dropping the connection.
 
>    - I have experienced no other networking problems with either test 
> machine.
> 
> Now I at least have a work around for the problem.  However, 
> I still believe 
> that the problem should be fixed and _is_ fixable within 
> Cygwin and/or 
> xfree86.  

We cannot work around every vendors bugs :]. True - this may not be an
Aventail Connect problem but all the indications so far are that it is.

<snip logic traing>

>    - they shouldn't be doing (things that have unpredictable 
> results in the 
> APIs), or
>    - aren't fully or properly supported in the Cygwin socket libs, or
>    - are unnecessarily complex or obscure.
> 
> Questions:
>    - Where is a good place in the source code of the Cygwin 
> and xfree86 
> libraries for me to start tracing these problems down?
>    - Where are all the socket calls made when establishing an 
> X client 
> connection?

There is quite likely a difference in the source port for the xclients
connections. I'd start there and write a test program and test server to
check the permutations of a,b,c and d,e,f above.

>    - Is it safe for me to assume that xfree86 is strictly doing 
> Cygwin/POSIX-type socket calls (therefore no direct calls to 
> the Win32 
> networking APIs)?

AFAIK XFree86/Cygwin only calls cygwin networking API's... all win32
networking calls are made from cygwin.
 
> Thank you all for your generous hints, suggestions, and 
> helpful responses.
> 
> Chris Landrieu
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
>