Dirk, Thanks for the recommendation. I gave it a try. Still no luck.
Dirk Fassbender wrote: > > 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 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/ >>> >>> >>> >> > > Hello, > > if you have more than one network card or more than one IP address > configured on your computer, it can be necessary to use the -from option > together with the -query option. > > X -query <remote host> -from <local address> > > Test it for all local IP addresses. > > Regards > Dirk > > -- > 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-tp22007087p22232905.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/