RE: Info on "Can't open display"

[Suhaib Siddiqi <ssiddiqi at inspirepharm dot com>]

Well, I am not convienced with your tests and explainations ;-)

BECAUSE, I tested a several VPN and Firewall software, except Aventail,
and none of them interfere with X-server.  Though, a couple of them
prompt, "client X is trying to connect to port so and so, Allow or deny" and
I
can add a rule to allow permanently, instead of clicking a YES button
eachtime.
As I see from mailing list, majority of the users who have display problems
are using Aventail.
It is not xclient as you try to explain in your reasonings... it is Aventail

stopping the Xclient to connect to X-server.

Suhaib

> -----Original Message-----
> From: Christopher Landrieu [mailto:landrieu@hotmail.com] 
> Sent: Thursday, June 14, 2001 1:19 AM
> 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.
> 
>    - 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.
> 
>    - 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).
> 
>    - 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.
> 
>    - 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").
> 
>    - 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.  It also is not necessarily the VPN software's 
> problem.  Clearly 
> there is some kind of bad interaction between the xclients 
> and the VPN 
> software, but since no other networking software (that I have 
> used) is 
> broken by the VPN software and since the other programs 
> generally do similar 
> networking stuff to that of the xclients,  I don't see any 
> reason why the 
> xclients can't be made to work okay with the VPN software 
> (without tweaking 
> the config file).  Unless the X client libs are using obscure 
> networking 
> features that are broken by the VPN software but are not used 
> by any of the 
> other software, it seems to me that, maybe, they are doing 
> things that:
>    - 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?
>    - 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)?
> 
> 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
>