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

Harold L Hunt II huntharo@msu.edu
Tue Nov 18 20:25:00 GMT 2003


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