Re: Info on "Can't open display"

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

----- Original Message -----
From: "Christopher Landrieu" <landrieu@hotmail.com>


> >From: "Robert Collins" <robert.collins@itdomain.com.au>
> >To: "Christopher Landrieu" <landrieu@hotmail.com>, > -----Original
> >Message-----
> > > From: Christopher Landrieu [mailto:landrieu@hotmail.com]
> > > To: cygwin-xfree@cygwin.com
>
> > >    - 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.
> >
> Actually, it is also behaving as a local xclient when using X
Forwarding.
> It tunnels X traffic from the remote machine (DISPLAY=localhost:10.0
on the
> remote host) through the SSH tunnel and redirects it to localhost port
6000
> on the desktop.  In this manner, it is behaving like a local xclient.
It
> doesn't do the actual X Protocol stuff, but it does the TCP/IP stuff
and
> gets the X Protocol stuff from the tunnel.

Chris, the important point is that TeraTermSSH does not do TCP/IP with
the xclient library code. I think we are all agreed that the X protocol
per se is not the fault.


> Unfortunately, I don't have any other xclients (other than
Cygwin/xfree86)
> to try.  Do you have any recommendations?

Uh yeah, try to establish answers to my fact finding questions suggested
below.

> > >    - 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
>
> Aren't all TCP/IP client programs unbound?  They don't choose an
individual
> port.  The operating system chooses the client's port.  Thats why the
port
> is different each time the client tries to open the connection.  The
OS also
> chooses what interface and IP address it should be bound to according
to its
> routing table.  Am I wrong here?  Its been a few years since I did
much
> socket UNIX programing.  My guess would be that the answer would be
"a)" for
> all clients.

Have you examined this or attempted to confirm your guess? I asked the
question _because_ there are multiple answers.

... You are wrong about "all tcp/ip client programs unbound". TCP/IP
client can ask for a random port on a random interface (a) or a specific
port on a random interface (still a - I wasn't worried about the
partocular port) or a random port on a given interface (one of b or c)
or a specific port on a specific interface (one of b or c).

> >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.
>
> My understanding on the server side is that the server can either bind
to a
> specific port on a specific interface or it can bind to a specific
port on
> all interfaces (loopback, ethernet card, PPP dial-up connection, or
what
> have you).  That particular version of Tomcat only allows you to bind
all
> interfaces (as opposed to one specific interface).  I would guess that
the X
> server does the same, right?  In any case, all servers must bind to a
port
> before listening on it, right?  So then e and f are the only
posibilities
> for a server application.  In this case Tomcat would be using f and I
would
> expect that xfree86 would do the same.

Chris, your guesssing is not helping debug the problem. Binding to a
specific port on all interfaces != being "unbound" where you bind to a
port, and no specific interface. (Binding to all interfaces you need to
call bind() multiple times oince for each interface). In any case, we
need to _know_ what is happening on your machine.

> > >    - 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)
> >
>
> Same answers (and questions) as before.
>
> > >    - 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.
>
> What is your reasoning?

You see the beginning of a normal 3-way handshake, and then a ack|fin
packet. That looks like a program other than the one listening on the
socket interfering with the tcp session to get the remote end to drop
it.

> > >    - 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>
>
> But it seems just as likely that it is an Xfree 86 problem as well.  I
> totally agree that other apps' bugs should remain other apps' bugs,
but it
> seems like alot of people have been having this same problem... even
without
> running VPN software.

To the best of my knowledge there is 1 windows 98 SE user with the
problem, and a bunch that had VPN related issues. There are a bunch with
other VPN products with no issues :-].

Occam's razor suggests that it's not the VPN capability, but the way in
which Aventail Connect and XFree86 are interacting. This will be
happening at the TCP/IP level, which is why the answers to my prior
questions are needed to make progress.

Rob


>
> I appreciate your comments and questions.
>
> Chris
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>