km4hr schrieb:
Phil,
Thanks for hanging in there and trying your best to help identify my
problem.
If I ever find the solution I will shout it from the mountain top!
I'd like to try cygwin-x on another Windows PC with less software installed
but my company's network is configured to block unknown MAC addresses. So I
can't use just any PC on my network. Furthermore I won't be getting any help
from my IT department. They're not sympathetic to anything Linux related.
Ironically, I work at a major university in the engineering department. They
see Linux as disruptive technology. We have Phd's who have written
dissertations on TCP/IP related stuff. I told one of them about my problem.
He wasn't interested.
As far as identifying BLODA software, that's way over my head. I'm already
well beyond my knowledge of Windows software and how Windows works in
general. Furthermore I already know everything I care to know about Windows.
I guess my next step is to retreat to VNC and see if that works. I just hate
giving up on xdmcp when it has worked well for me before. I guess I haven't
used it since cygwin-x went from xfree to Xorg. But I don't think cygwin-x
is the problem since Xming and X-Win32 don't work either. I think you're
correct, something is blocking the communications.
BTW, why did you suggest I telnet to port 6000? Isn't port 177 the one that
xdmcp uses to initiate sessions?
I noticed in my PC's task bar that I have anti-virus software from Trend
Micro installed. I called their support number. To their credit the support
engineer helped me shut down their software completely. He stayed on the
line to talk me through the process. Unfortunately cygwin-x still didn't
work. The engineer assured me that the test confirmed that Trend Micro
software is not the problem. I hope he's right. There's just too may
variables here.
Phil Betts-2 wrote:
km4hr wrote:
Phil Betts-2 wrote:
km4hr wrote:
Perhaps you missed my suggestions here:
http://cygwin.com/ml/cygwin-xfree/2009-02/msg00222.html
Try the telnet check first to see if the port is accessible from
Windows
because that only takes a few seconds. (Make sure you run the cygwin
telnet.exe)
Phil,
Thanks for hanging in there.
I tried your telnet suggestion. I get the following:
$telnet xxx.xxx.xxx.xxx 6000
trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
The above is all I get. A login prompt never appears. I waited for
several minutes.
When I press Ctrl-c I get:
Connection closed by foreign host.
If I telnet using an unopen port I the response gets past the
trying
statement.
Your quoting went a bit wrong there.
Sorry, I should have explained that that was the expected outcome. If
you get the Connected to message, the port is open and you can close
the connection. The proper way to terminated a telnet session from that
situation is to press Ctrl-] (the Escape character mentioned in the
message). You then get a telnet prompt, where you just type quit.
You wouldn't normally expect a prompt (unless the port was 23 - telnet's
own). In theory, if you knew enough about the protocol expected on the
opened port, you could simulate a normal connection and debug the
connection using telnet, but you have to have a certain masochistic
streak to try it!
So, now we know that the port is accessible from Windows. In that case,
it *should* work, so something else is interfering.
Have you investigated the BLODA angle? Prime suspects are anti-virus
and
other security software, but hardware drivers have caused problems
too.
These programs inject themselves into every running process at a fairly
low level and, whilst they are mostly benign, can cause nasty, spurious
problems, particularly when the code you are trying to run is slightly
off the beaten track. X and XCMCP probably falls into that category for
Windows machines.
The usual advice is to uninstall these, rather than just disable them.
The faulty components are frequently left in place when disabled.
Once
you have ruled out a candidate, you can reinstall it. If you do find
one
that is causing the problem, it may be possible to configure it in a way
which avoids the problem (e.g. disabling real-time virus scanning).
You can often spot BLODA by running the program which is failing, and
then seeing which DLLs are loaded using something like Process Explorer.
Any unexpected DLLs, particularly if not under C:\Windows or C:\cygwin
are prime suspects. In your case, because the -query option is failing,
you won't get chance to see the DLLs before X terminates, so you could
just start a normal server (e.g. via startxwin.bat) instead.
You may find that an app that is not on the BLODA is causing the
problem.
If so, a message to the main cygwin list would be appreciated so that
the
BLODA can be updated.
If the BLODA hunt fails, you could try running the server via strace so
that the point of failure might be spotted, but I'm not familiar with
the
source. Yaakov or Jon
