XWin works on Win2K but not on some WinXP clients [FIXED]

Harold L Hunt II huntharo@msu.edu
Wed Nov 19 21:41:00 GMT 2003


Kirk,

Did you then do a test login with startxdmcp.bat with the hosts setup?

Harold

Woellert, Kirk D. wrote:

> nslookup from the linux box reported the correct machine name for the WinXP
> client. Also the guy with the Win2K machine that can connect does not have
> his IP address in the hosts file.
> 
> nevertheless did the test Igor suggested.
> 
> # Do not remove the following line, or various programs
> # that require network functionality will fail.
> 127.0.0.1       localhost.localdomain   localhost
> 137.51.14.130   gaia.ad.tasc.com        gaia
> 137.51.14.56    lyceum.ad.tasc.com      lyceum
> 137.51.14.54    ngc-d4o1xu3vg29.ad.tasc.com ngc-d4o1xu3vg29
> ~
> ~
> ~
> ~
> ~
> "hosts" 8L, 283C written
> [kdw@gaia /etc]# kill -USR1 `cat /var/run/gdm.pid`
> [kdw@gaia /etc]# telinit 3
> [kdw@gaia /etc]# telinit 5
> [kdw@gaia /etc]#
> 
> [kdw@gaia /etc]# nslookup 137.51.14.54
> Note:  nslookup is deprecated and may be removed from future releases.
> Consider using the `dig' or `host' programs instead.  Run nslookup with
> the `-sil[ent]' option to prevent this message from appearing.
> Server:         137.51.60.36
> Address:        137.51.60.36#53
> 
> 54.14.51.137.in-addr.arpa       name = ngc-d4o1xu3vg29.
> 
> [kdw@gaia /etc]#
> 
> 
> -----Original Message-----
> From: Igor Pechtchanski [mailto:pechtcha@cs.nyu.edu]
> Sent: Tuesday, November 18, 2003 4:07 PM
> To: cygwin-xfree@cygwin.com
> Cc: Woellert, Kirk D.
> Subject: Re: XWin works on Win2K but not on some WinXP clients [FIXED]
> 
> 
> Kirk,
> 
> Check /var/log/messages and see if there are any from gdm.  This may be a
> DNS lookup issue (i.e., your XP machine is not registered in DNS, or
> registered, but not with the correct name).  Confirm by "nslookup YOUR_IP"
> from the Linux machine.  If it is a DNS issue, try adding your XP machine
> to /etc/hosts and restarting gdm ("kill -USR1 `cat /var/run/gdm.pid`").
> 	Igor
> 
> On Tue, 18 Nov 2003, Harold L Hunt II wrote:
> 
> 
>>So echo on UDP port 177 works fine.  This is not good.  There must be
>>something else in the gdm conf on the linux box that explicitly denies
>>gdm connections from the Windows XP machine's IP addresses, since it
>>worked fine when using 10.0.0.x addresses.  Anyway you can change the IP
>>of the XP machine to one not previously used as a test?
>>
>>Harold
>>
>>Woellert, Kirk D. wrote:
>>
>>
>>>1. Edited the echo-upd file in the xinetd.d folder. Changed the default
> 
> port
> 
>>>from "7" to "177"...
>>>
>>>[root@gaia xinetd.d]# cat echo-udp
>>># default: off
>>># description: An xinetd internal service which echo's characters back
> 
> to
> 
>>>clients. \
>>># This is the udp version.
>>>service echo
>>>{
>>>        disable = no
>>>        type            = INTERNAL UNLISTED
>>>        id              = echo-dgram
>>>        socket_type     = dgram
>>>        protocol        = udp
>>>        user            = root
>>>        wait            = yes
>>>        port            = 177
>>>}
>>>[root@gaia xinetd.d]#
>>>
>>>2. Did a grep just to ensure gdm was not gonna respond to my upd
> 
> packets...
> 
>>>[root@gaia xinetd.d]# ps -ef |grep xdm
>>>root      2328  1912  0 18:12 pts/0    00:00:00 grep xdm
>>>[root@gaia xinetd.d]#
>>>
>>>3. Ran a upd echo test from the WinXP client to the Linux box using a
> 
> Java
> 
>>>echo client....
>>>
>>>C:\Bin>java -jar UDPEchoClient.jar 137.51.14.130:177
>>>64 bytes from 137.51.14.130: seq no 0 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 1 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 2 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 3 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 4 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 5 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 6 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 7 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 8 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 9 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 10 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 11 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 12 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 13 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 14 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 15 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 16 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 17 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 18 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 19 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 20 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 21 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 22 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 23 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 24 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 25 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 26 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 27 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 28 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 29 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 30 time=0 ms
>>>64 bytes from 137.51.14.130: seq no 31 time=0 ms
>>>32 packets transmitted, 32 packets received, 0% packet loss
>>>round-trip min/avg/max = 0/0.0/0 ms
>>>
>>>C:\Bin>
>>>
>>>Having trouble getting Java to run on the Linux box, so I could not
> 
> complete
> 
>>>the echo test from the Linux host to the WinXP client.
>>>
>>>-----Original Message-----
>>>From: Harold L Hunt II [mailto:huntharo@msu.edu]
>>>Sent: Monday, November 17, 2003 4:41 PM
>>>To: cygwin-xfree@cygwin.com
>>>Subject: Re: XWin works on Win2K but not on some WinXP clients [FIXED]
>>>
>>>
>>>Kirk,
>>>
>>>Well then, I suppose the next step would be to do a "telinit 3" (to stop
>>>gdm), then edit xinetd conf file to run "echo" on UDP port 177, restart
>>>xinetd, then use that udp echo client that we found to test if echo
>>>works from the Windows XP machine plugged into its normal jack to gaia
>>>plugged into its normal jack.  We know that echo worked on UDP port 7,
>>>but proving that it does or does not work on UDP port 177 would tell us
>>>if they know what they are talking about :)
>>>
>>>Harold
>>>
>>>Woellert, Kirk D. wrote:
>>>
>>>
>>>
>>>>I aksed corporate IS if they were doing an port blocking/filtering
> 
> within
> 
>>>>our LAN. They replied:
>>>>
>>>>"There should be no port blocking within the corp. LAN. - only in/out
>>>>to the Internet and in/out of DMZs."
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Harold L Hunt II [mailto:huntharo@msu.edu]
>>>>Sent: Monday, November 17, 2003 10:45 AM
>>>>To: cygwin-xfree@cygwin.com
>>>>Subject: Re: XWin works on Win2K but not on some WinXP clients [FIXED]
>>>>
>>>>
>>>>Kirk Woellert's problem with XP clients has been fixed, sort of.
>>>>
>>>>I talked to him on the phone for a few hours on Friday and walked him
>>>>through some debugging.
>>>>
>>>>
>>>>Here is what we found out:
>>>>
>>>>1) We could ssh from XP to Linux (TCP protocol).
>>>>
>>>>2) We could tunnel X apps over ssh from the Linux box to display on the
>>>>XP box (TCP protocol).
>>>>
>>>>3) We could natively display X apps by exporting DISPLAY on Linux box,
>>>>pointed to XP box (TCP protocol).
>>>>
>>>>4) We could not (nor could X-Win32) get an XDMCP login on the XP box for
>>>>the Linux box (UDP protocol).
>>>>
>>>>5) We could run the echo service on the Linux box on port 7 and use a
>>>>Java echo client for UDP to verify that UDP to Linux box worked (UDP
>>>>protocol).
>>>>
>>>>6) It was revealed that there are really two parts of the network here.
>>>> Not much is known about whether port blocking is in effect between the
>>>>two parts.
>>>>
>>>>7) Removing the troubled hosts from the network and hooking them to a
>>>>stand-alone hub with assigned IP addresses allowed XDMCP to work.
>>>>
>>>>8) We thus confirmed in #5 that UDP was not blocked in general, but #7
>>>>indicates that UDP port 177 is blocked between the segments.  It turns
>>>>out that all of the Windows 2000 machines were on one "segment", while
>>>>the Windows XP machines were on another "segment".  The problem was not
>>>>the OS, it was that one segment has UDP port 177 blocked.
>>>>
>>>>
>>>>Thus, we determined that the problem is in the network that the machines
>>>>are attached to; this may or may not be by design.  In any case, it
>>>>isn't a problem with Cygwin/X.  :)
>>>>
>>>>Harold
> 
> 



More information about the Cygwin-xfree mailing list