Re: Info on "Can't open display"

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

----- Original Message -----
From: "Stephen Mathezer" <mathezer@yahoo.com>
To: <cygwin-xfree@cygwin.com>
Cc: <robert.collins@itdomain.com.au>; <ssiddiqi@inspirepharm.com>;
<landrieu@hotmail.com>
Sent: Saturday, June 16, 2001 7:56 AM
Subject: Re: Info on "Can't open display"


>
> I have been watching this thread closely but I haven't piped up until
> now because I don't really have a lot to offer.
>
> First off, I have a friend running Windows ME who is encountering
> exactly the same symptoms in every detail.  He does not have ANY VPN
> software installed on his machine.  THIS PROBLEM IS *NOT* restricted
to
> VPN users, at least there are quite a few more than 1 (I checked the
> archives) without a VPN client that have the problem. I posted a
> question on behalf of my buddy a month or so ago and received no
response.
> Since he isn't on the list and I don't have the problem, I haven't had
> much to say on this one as I figured that I can't be of much help.

Oops! That email must have slipped through.

What I think Suhaib and Harold need, is either
a) a test box with the problem (Saying "install ME" doesn't help - not
all ME users have the fault. Like Aventail Connect - we don't know that
all Aventail Connect users experience the fault... I suspect that if
someone contributed a licence for Aventail Connect to Suhaib or Harold
they'd be willing to try installing it and seeing if the fault arises.
b) Some volunteer willing to go through some detailed tests to pinpoint
the differences occuring between working local-local connections and
non-working local-local connections.

> I do have a few comments though (OK, I got a little long winded below
> but I think this thread needs to be brought back to the relevant
points)
>
> Kudos to Robert for politely explaining the same things over and over
> due to people not reading what he is saying.

:]

> -Telnet to localhost:6000 is, while not complete in all respects, at
> least a decent indication that the VPN client is not doing something
as
> basic as blocking all connections to localhost:6000 as some seem to
> imply. Can somebody please explain to me why TerreTermSSH X forwarding
> (see below), displaying remote X clients on the cygwin
> server, and telnet to localhost:6000 all work if the VPN software is
> truly blocking ports.

Suhaib made a _very_ good point. X (may be)/(is) using AF_UNIX sockets
for local connections. Cygwin1.dll emulates such sockets using normal
win32 sockets and a file on disk. If thats the case any win32 only
program is not a valid example of a working tool. What would be a valid
comparison is a test client-server package that use AF_UNIX sockets -
say CORBA based or something similar.

> -Since the problem occurs even if the VPN client is not running, it is
> obviously not some case of the VPN client not allowing split-tunneling
> or something like that.  This has to come down to some interaction
with
> the TCP stack.  Then again, why does adding exceptions to the VPN
client
> cause things to work even when the client isn't running?

Maybe "Not running" means "not establishing IPSEC connections" as
opposed to "all alterations removed".

> -TeraTermSSH (like any SSH client) can forward X windows connections
from
> remote machines.  This requires the SSH client running under 98 to
> connect to localhost:6000 to proxy the X windows request that it is
> forwarding over the encrypted channel from the remote machine.  This
has
> been repeated ad nauseum on the list.  TeraTermSSH is a perfectly good
> example of an X Windows client that works.  That being said, it
> certainly would make sense to try another.

I still disagree on that: TeraTermSSH is not using AF_UNIX sockets when
it does that.

> -X servers typically (and yes I just checked mine) listen on ALL local
> IP addresses (ie *.6000). Clients will connect from some random source
> port to port 6000 on $DISPLAY.
>
> I too would have tended to blame the VPN client on this one except for
the
> fact that other X clients do work.  Trying another X client and
another
> X server would certainly provide more info.

Thanks.

> A couple of things that I haven't seen suggested which may be worth
> trying arei:
>
> -Running something similar to ktrace or truss (does sysinternals
>  have something similar?) against both client and server.

I provided a link to TDIMon from sysinternals in my last email :]. It
provides a TDI level trace of all system activity, and you can filter
down to application/.exe.

> -Getting debug versions of client and server and running the client
>  under GDB and/or attaching to the server and following the logic
where
>  the connection is failing.

My suspicion is that a debug 'kernel' - cygwin1.dll - is all that will
be needed. Certainly that _will_ be needed to see where the connection
is failing, because the actual win32 call occurs from cygwin, not the
xclient or server.

> -As has been suggested by othersi, trying other clients to cygwin
server
> and cygwin clients to other server would be very valuable.
>
>
> -Steve

Thanks for your input Steve - much appreciated.

Rob