"-query" not working on cygwin/windows

[km4hr]

I can't get "-query" to do anything. I only get a grey screen.

Do you have disable firewalling, or open some ports, or whatever on the Windows box?
I completely disabled my Windows firewall (I think) but still no joy.

I'm completely illiterate on Windows. I don't care to know anything about Windows really. I just need cookbook directions to get cygwin/x working.

I've also tried Xming. Same result, no response using "-query".

I have evidence that xdmcp is set up correctly on the linux box. I can open a terminal window (Alt F2) on the linux box and run "X :1 -query <linux hostname>". The gdm login window appears and I can log in.

My network connection seems ok between the Windows box and the Linux box. Telnet works fine.

Are there any log files that might help troubleshoot the problem?

I've done everything I can think of.

[Jon TURNEY]

km4hr wrote:

> I can't get "-query" to do anything. I only get a grey screen.
>
> Do you have disable firewalling, or open some ports, or whatever on the
> Windows box?
> I completely disabled my Windows firewall (I think) but still no joy.
>
> I'm completely illiterate on Windows. I don't care to know anything about
> Windows really. I just need cookbook directions to get cygwin/x working.
>
> I've also tried Xming. Same result, no response using "-query".
>
> I have evidence that xdmcp is set up correctly on the linux box. I can open
> a terminal window (Alt F2) on the linux box and run "X :1 -query <linux
> hostname>". The gdm login window appears and I can log in.

You may well need to adjust the configuration on your linux box to permit
remote XDMCP connections.

I'm assuming you've checked the FAQ
http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-xdmcp-query

You should look for instructions specific to your linux distro on configuring
XDMCP for remote access, for e.g. you might need allow remote access in
tcpwrappers
http://projects.gnome.org/gdm/docs/2.14/security.html#xdmcpaccess

> My network connection seems ok between the Windows box and the Linux box.
> Telnet works fine.
>
> Are there any log files that might help troubleshoot the problem?

Yes, but they are probably on the linux host.  Cygwin/X can't know why the
connection is refused.

> I've done everything I can think of.


--
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/

[km4hr]

This is an update on my hard-fought attempt to get "-query" access to a linux xdmcp server running CentOS 5 from my Windows PC running cygwin-x.

I installed X-Win32 (a commercial X-server) on my Windows PC. Unlike cygwin-x and Xming the X-Win32 server does detect available xdmcp hosts when I use the "-broadcast" switch. But I can only get a login prompt one of them, an HPUX host. My linux box is in the broadcast list but X-Win32 won't connect to it. No reason or error message is given. I may go ahead and purchase a copy X-Win32 just so I can get their tech support people involved.

Anyway, my question is, why won't cygwin-x bring up the same "-broadcast" list as X-Win32?

Any suggestions are greatly appreciated.

[Phil Betts-2]

km4hr wrote:
> This is an update on my hard-fought attempt to get "-query" access to
a
> linux
> xdmcp server running CentOS 5 from my Windows PC running cygwin-x.
>
> I installed X-Win32 (a commercial X-server) on my Windows PC. Unlike
> cygwin-x and Xming the X-Win32 server does detect available xdmcp
hosts
> when
> I use the "-broadcast" switch. But I can only get a login prompt one
of

> them, an HPUX host. My linux box is in the broadcast list but X-Win32
> won't
> connect to it. No reason or error message is given. I may go ahead and
> purchase a copy X-Win32 just so I can get their tech support people
> involved.
>
> Anyway, my question is, why won't cygwin-x bring up the same "-
> broadcast"
> list as X-Win32?
>
> Any suggestions are greatly appreciated.

The XWin -broadcast option connects to "the first XDM machine to
respond".  I can only assume that your Linux box responded first, but
denied access for the same reason that -query fails.

I think you are looking in the wrong place for the answer.  Your mail
about the -ac option also suggests you are blaming XWin.  It is the
Linux box which is denying you access, and you need to look on that
box for the answer.

Try looking in the logs on your Linux box as Jon suggested.  Reading
the man pages for your distro will tell you where the logs are.  Try
"man xdm" and "man xauth", for a start.  You are also likely to get
less speculative answers by asking on the forum specific to your
Linux distribution.

Perhaps it would be better if you told us what you are trying to
achieve rather than what you are attempting in order to achieve it.  
In other words, you have told us that you can't connect using -query,
rather than WHY you are trying to connect using XDMCP.  If you are
simply trying to get Linux apps to display on your Windows box, then
you are probably better off using the ssh -Y method rather than
XDMCP.

If you haven't done so already, the FAQ should give you some useful
pointers, particularly sections 6 & 7:
  http://x.cygwin.com/docs/faq/cygwin-x-faq.html
Also try:
  http://en.tldp.org/HOWTO/XDMCP-HOWTO/
  http://www.xs4all.nl/~zweije/xauth.html


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/

[km4hr]

This is a update including further information regarding my quest to get cygwin/x to connect to my CentOS linux server via xdmcp.

I believe I have isolated the problem to either cygwin/x or Windows, probably Windows because no X-server that I've tried works. I've tried cygwin/x, Xming, and X-Win32. I've isolated the problem by booting my Windows PC from a Linux LiveCD (pclos). Using the pclos X-server I successfully connected to my CentOS host using "X :1 -query <centos box>" . It works perfectly. A beautiful gdm login screen pops up immediately. I think this proves that xdmcp is configured correctly on the CentOS host and that my network is not contributing to the problem.

The above successful connection seems to isolate the problem to either cygwin/x, Windows, or the combination of both. Although no one on this site has confirmed that they are actually using cygwin/x successfully in an xdmcp environment I'm assuming that it does work for somebody. If that assumption is correct then it appears something in my Windows configuration is blocking cygwin/x, and the other X-servers, from working properly. Could it be that necessary ports on my Windows box are blocked? I have my Windows firewall turned off. But I'm not sure that disabling the firewall opens the ports. Do I even need to open certain ports on the Windows box? This is an area that I know virtually nothing about.

Phil, you had several questions. One was, "why do you want to use xdmcp?". I want to use xdmcp for the same reason anyone wants to use it and for the same reason that it exists. That is, I want to log in to a complete gnome environment. I don't want to run individual applications. You suggested I contact someone who is familiar with my Linux distribution to make sure I have xdmcp set up correctly. I have already done that. I am asking many of the same questions on the CentOS forum that I'm asking here. You gave me several links to study. I've read those and more. I've been at this for days. You asked why I'm "blaming cygwin". I don't know what I said that made you think that. I'm not blaming anybody or anything. I'm just trying to get a gdm login screen on my PC. My problem may be related to Windows security. Can you suggest a good forum where I can find an expert on that? I don't know any Windows experts personally. I'm not sure they exist.

[X23G8c]

        You've read this, yes?

http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-xdmcp-query

        Specifically, check your Windows firewall config.  You will need to explicitly open the X11 port, as there is, IIUC, no outgoing packet from that port.


        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/

[km4hr]

Yes, I've read the information at the link you provided. It says to open port 177/UDP and ports 6000-6005(TCP). But it doesn't say whether that applies to the PC where the X-server is running, or just the xdmcp host. I'm 99% sure I've got those ports open on my CentOS host (the xdmcp server). There's a GUI screen specifically for doing that. And I've done it. But I don't know whether the ports are open on my Windows PC where the X-server is running. I turned my Windows firewall off. But I don't know if that opens the ports. So I have two questions. First, do I even need to open the ports on Windows? Second, how do I do it? I think I really need a Windows XP firewall/ports expert. But I don't know where to find one. If any here knows how to tell what ports are open in Windows, please respond.

Thanks for your recommendation.
 

X23G8c wrote:

        You've read this, yes?

http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-xdmcp-query

        Specifically, check your Windows firewall config.  You will need to explicitly open the X11 port, as there is, IIUC, no outgoing packet from that port.


        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/

[km4hr]

I've found an article on the internet that explains how to open ports in Windows.
I'll try it tomorrow even though I don't know if it's necessary.




Yes, I've read the information at the link you provided. It says to open port 177/UDP and ports 6000-6005(TCP). But it doesn't say whether that applies to the PC where the X-server is running, or just the xdmcp host. I'm 99% sure I've got those ports open on my CentOS host (the xdmcp server). There's a GUI screen specifically for doing that. And I've done it. But I don't know whether the ports are open on my Windows PC where the X-server is running. I turned my Windows firewall off. But I don't know if that opens the ports. So I have two questions. First, do I even need to open the ports on Windows? Second, how do I do it? I think I really need a Windows XP firewall/ports expert. But I don't know where to find one. If any here knows how to tell what ports are open in Windows, please respond.

Thanks for your recommendation.
 

X23G8c wrote:

        You've read this, yes?

http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-xdmcp-query

        Specifically, check your Windows firewall config.  You will need to explicitly open the X11 port, as there is, IIUC, no outgoing packet from that port.


        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/

[Larry Hall (Cygwin X)]

km4hr wrote:
> I've found an article on the internet that explains
> http://support.microsoft.com/kb/842242 how to open ports  in Windows.
> I'll try it tomorrow even though I don't know if it's necessary.

If you are confident that you turned the Windows firewall off and you
have no other firewalls or other security software installed on this
machine, then you don't need to follow this prescription to test X.
In order to run X properly with the firewall on, following the article
wouldn't be a bad idea if you need help when doing the firewall
configuration.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

--
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/

[Phil Betts-2]

km4hr wrote:

> This is a update including further information regarding my quest to
> get cygwin/x to connect to my CentOS linux server via xdmcp.
>
> I believe I have isolated the problem to either cygwin/x or Windows,
> probably Windows because no X-server that I've tried works. I've tried
> cygwin/x, Xming, and X-Win32. I've isolated the problem by booting my
> Windows PC from a Linux LiveCD (pclos). Using the pclos X-server I
> successfully connected to my CentOS host using "X :1 -query <centos
> box>" .
> It works perfectly. A beautiful gdm login screen pops up immediately.

I
> think this proves that xdmcp is configured correctly on the CentOS
host
> and that my network is not contributing to the problem.

OK.  So the problem seems to be that X cannot communicate with the
remote
host.  Do you have another host you could connect to, and if so do you
have the same problem?  You could try "telnet remotehost 6000".  If you
can connect, then the X port (6000) is open, and the problem is protocol
related.  If you get "connection refused", then the port is closed.

> The above successful connection seems to isolate the problem to either
> cygwin/x, Windows, or the combination of both. Although no one on this
> site has confirmed that they are actually using cygwin/x successfully
> in an xdmcp environment I'm assuming that it does work for somebody.

I have used it successfully, but that was a few years ago.

> If that assumption is correct then it appears something in my Windows
> configuration is blocking cygwin/x, and the other X-servers, from
> working properly. Could it be that necessary ports on my Windows box
> are blocked? I have my Windows firewall turned off. But I'm not sure
> that disabling the firewall opens the ports. Do I even need to open
> certain ports on the Windows box? This is an area that I know
virtually
> nothing about.

Do you have any other security software installed?  Perhaps you have
http://cygwin.com/acronyms/#BLODA  These are applications/drivers (often
apparently nothing to do with the problem, e.g. Logitech Webcam), that
inject their code into each process and cause all sorts of weird
problems.

> Phil, you had several questions. One was, "why do you want to use
> xdmcp?". I want to use xdmcp for the same reason anyone wants to use
it
> and for the same reason that it exists. That is, I want to log in to a
> complete gnome environment. I don't want to run individual
> applications.

That's fine.  I only asked because there have been several queries over
the years from people who did just want to display individual apps and
thought XDMCP was the way to go because it showed up first in a web
search.

> You suggested I contact someone who is familiar with my Linux
> distribution to make sure I have xdmcp set up correctly. I have
already
> done that. I am asking many of the same questions on the CentOS forum
> that I'm asking here. You gave me several links to study. I've read
> those and more. I've been at this for days.

That's good (the researching, not the outcome ;-).  As with any fault
finding, a lot of time can be saved if we know what has already been
read/tried.

> You asked why I'm "blaming cygwin". I don't know what I said that
> made you think that.

It was partly your other thread about the -ac option which suggested
that
you though XWin was denying the access.

> I'm not blaming anybody or anything. I'm just trying to get a gdm
login
> screen on my PC.

I understand.  Perhaps "blaming" was too loaded a word to use.

> My problem may be related to Windows security.
> Can you suggest a good forum where I can find an expert on that? I
> don't know any Windows experts personally. I'm not sure they exist.

They do exist, but they come at a price.  Most of the self-professed
experts I see on the web are pretty poor.

I think investigating the BLODA avenue is perhaps your best course of
action for now.  It's amazing how many of the seemingly intractable
problems turn out to be caused by some dodgy app.

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/

[km4hr]

Well, I have now turned on all relevant ports in the Windows firewall. I still can't connnect.
I turned on port 177(UDP) and 6000-6006(TCP).  I even turned on extra ports as recommend by this source.

I'm about out of ideas. I love to hear some more.

I don't know how firewalls work but on the linux host side (CentOS) simplyturning off the firewall did not open the ports. I had to turn the firewall on and specify which ports to open. Otherwise no computers could connect via xdmcp over the network.

Thanks for you consideration.

Larry Hall (Cygwin X) wrote:

km4hr wrote:
> I've found an article on the internet that explains
> http://support.microsoft.com/kb/842242 how to open ports  in Windows.
> I'll try it tomorrow even though I don't know if it's necessary.

If you are confident that you turned the Windows firewall off and you
have no other firewalls or other security software installed on this
machine, then you don't need to follow this prescription to test X.
In order to run X properly with the firewall on, following the article
wouldn't be a bad idea if you need help when doing the firewall
configuration.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

--
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/

[Phil Betts-2]

km4hr wrote:
> Well, I have now turned on all relevant ports in the Windows firewall.
> I still can't connnect.
> I turned on port 177(UDP) and 6000-6006(TCP).  I even turned on extra
> ports as recommend by
>
http://www.starnet.com/xwin32kb/What_ports_need_to_be_opened_for_XDMCP/
> this source.
>
> I'm about out of ideas. I love to hear some more.

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)

> I don't know how firewalls work but on the linux host side (CentOS)
> simplyturning off the firewall did not open the ports. I had to turn
> the firewall on and specify which ports to open. Otherwise no
computers
> could connect via xdmcp over the network.

I've not used CentOS, but other distros I've used start with a default
set of firewall rules that just block all externally initiated
connections.  Turning off the firewall actually leaves those rules in
force.  Turning on the firewall enables more complex rules.  If they
didn't do this, then you'd be wide open to attack before you'd
configured
the system.  You can disable the firewall completely, but I think it
would be irresponsible to post how here.  If you must, man iptables is
your friend.

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/

[km4hr]

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.

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/

[Phil Betts-2]

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/

[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/

[Dirk Fassbender]

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/

[km4hr]

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/

[km4hr]

How do know which which ports are open on a Windows PC?

I need ports 177/UDP and 6000-6006/TCP open for xdmcp "-query". (Or so I understand. I can't find any clear instructions on this.)

At cygwin shell prompt I enter "netstat -na |grep 600*"
I get this:
UDP    0.0.0.0:6000   *:*
UDP    0.0.0.0:6001   *:*
UDP    0.0.0.0:6002   *:*
..etc..

"netstat -na | grep 177" returns nothing.

I get the above responses whether my Windows firewall is on or off.

Also, why does netstat say UDP in the above responses? I specifically enabled these ports as TCP in the Windows firewall configuration screen.

I configured port 177 just like ports 6000-6005. But it never shows up in "netstat -na". Why?

Do I have to reboot the computer to activate changes made in the Windows firewall configuration?

Come on, there must be a Windows networking expert out there somewhere?

thanks,

[Mark Geisert]

km4hr writes:

> At cygwin shell prompt I enter "netstat -na |grep 600*"
> I get this:
> UDP    0.0.0.0:6000   *:*
> UDP    0.0.0.0:6001   *:*
> UDP    0.0.0.0:6002   *:*
> ..etc..
>
> "netstat -na | grep 177" returns nothing.
>
> I get the above responses whether my Windows firewall is on or off.
>
> Also, why does netstat say UDP in the above responses? I specifically
> enabled these ports as TCP in the Windows firewall configuration screen.
>
> I configured port 177 just like ports 6000-6005. But it never shows up in
> "netstat -na". Why?

If you're OK with turning off Windows Firewall, do that, to remove one potential
area of networking conflict.  Leave it off until you get things working and then
add it back in afterwards.

Having the Firewall open a port just means that some program on your PC trying
to listen on that port will actually receive traffic from the network.  If the
port is closed the program might be able to listen on that port but it won't
receive anything because the Firewall has blocked the traffic to it.

Netstat is showing you something different: the ports that are currently being
listened on by running programs.  Use the '-o' option to netstat to have it
print the Windows pids of the listening programs.  E.g., 'netstat -ano'.
Sometimes Cygwin pids are different from Windows pids for reasons not important
here.  Use the Windows Task Manager to identify Cygwin processes from Windows
pids if necessary.

I don't know why your netstat display shows UDP.  If I were to speculate, I'd
say you mistakenly enabled UDP rather than TCP in the Firewall and the X Server
was able to open listening sockets for UDP datagrams.  There's no 177 in your
netstat display because there probably isn't any program currently running to
listen on that port.  Do you have to start xdmcp manually?  I don't know how
that works.  I just know that I see TCP for ports 6000 and up when I run the
Cygwin X server.

..mark


--
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/