"-query" not working on cygwin/windows

[km4hr]

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 would probably be better at making sense of that.
> 
> Phil
> -- 
> 
> 
> This email has been scanned by Ascribe PLC using Microsoft Antigen for
> Exchange.
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://x.cygwin.com/docs/
> FAQ:                   http://x.cygwin.com/docs/faq/
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/%22-query%22-not-working-on-cygwin-windows-tp22007087p22217645.html
Sent from the cygwin-xfree mailing list archive at Nabble.com.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/