Re: -query not working on cygwin/windows
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
RE: Reproducing the cygwin X clipboard problems
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Jon TURNEY Sent: Wednesday, February 25, 2009 2:52 PM I've built a version of 1.5.3-7, with this patch reverted and lots more clipboard debugging added. You can download it from [2] It would be most helpful if you could try this and see if the clipboard problems you are seeing are changed at all. [2] ftp://cygwin.com/pub/cygwinx/XWin.20090225214130.exe.bz2 Both startx and startxwin.bat (i.e. start server menu item), which formerly experienced severe clipboard problems, are now running cleanly! Thanks, Mike -- 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/
Re: -query not working on cygwin/windows
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
Re: Reproducing the cygwin X clipboard problems
On Wed, Feb 25, 2009 at 5:51 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: I've built a version of 1.5.3-7, with this patch reverted and lots more clipboard debugging added. You can download it from [2] It would be most helpful if you could try this and see if the clipboard problems you are seeing are changed at all. I'm afraid I didn't have the same experience as Mike. I've downloaded and ran your patched XWin. The result was non-deterministic: it typically starts good, but then the problem returns, and may go away and return again, depending on what I do. However, I was never able to replicate. Alas, I currently don't have time to come up with some more coherent observations. I will try it out again during the weekend and report back. --Dan -- 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/
Re: XWin.exe crashing at startup
Thought I'd reply to the list about the resolution to this, since somebody just asked me about this off-list: 'startxwin.sh' from a bash window works whereas 'startx' doesn't (also works: 'startxwin.bat' from a windows cmd line). It seems startx is broken on cygwin. Andrew On Sat, Dec 6, 2008 at 5:57 PM, Andrew Allen a2i...@gmail.com wrote: I'm trying to start XWin.exe on a fresh cygwin install via startx and am getting the following: bash-3.2$ startx xauth: creating new authority file /cygdrive/c/Users/anallen/.serverauth.4156 giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. After the xauth message, I get a frame of a window titled Cygwin/X:0.0 (but nothing in the window), the computer screen greys out, and a window pops up saying: XWin.exe has stopped working. Windows is checking for a solution to the problem... A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. I'm running Windows Vista Enterprise Service Pack 1 snip -- 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/
RE: XWin.exe crashing at startup
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Andrew Allen Sent: Thursday, February 26, 2009 5:07 PM Thought I'd reply to the list about the resolution to this, since somebody just asked me about this off-list: 'startxwin.sh' from a bash window works whereas 'startx' doesn't (also works: 'startxwin.bat' from a windows cmd line). Try: startx -- -multiwindow -clipboard It seems startx is broken on cygwin. Not really, although the behavior changed a little a few months ago (I didn't need the flags before). I'll see if I can try this on Vista tonight. HTH, Mike -- 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/
