[svlug] Mostly resolved (and it's _weird_) Re: XDMCP server issues

Karsten M. Self kmself at ix.netcom.com
Tue Apr 5 18:44:55 PDT 2005


on Sat, Apr 02, 2005 at 11:46:03PM -0800, Karsten M. Self (kmself at ix.netcom.com) wrote:
> This is mostly a "how should I go about troubleshooting" question.

[X, VNC, XDMCP, inetd.conf]

> Everything worked dandy prior to the system being moved across the lab,
> modulo about two weeks (spring break).  Local console X login worked,
> remote XDMCP X login worked, and remote VNC with XDMCP login worked.
> 
> 
> Now:
> 
>   - Local X11 login via kdm works.
> 
>   - Remote X11 session with "query" or "broadcast" *doesn't* work.  The
>     local X11 server starts (herringbone pattern), but the login/chooser
>     screen never appears.
> 
>   - Remote VNC sesssion doesn't succeed.  The VNC session connection is
>     made, the appropriate resolution (per the assigned ports above) is
>     selected, and X displays its herringbone pattern.  But no kdm login
>     appears.
> 
> 
> I've looked for any output in system logs, and there simply doesn't
> appear to be any.  'find /var/log -type f -maxdepth 2 -mtime -2 -print0
> | xargs -0 grep kdm' turns up a few false positives.  No logfiles appear
> to be written as the session starts.  I'm sort of stuck for diagnosing
> this.  Is there any way to increase verbosity of either the VNC server
> or kdm?
> 
> Subsequently I've found the following post via Google which suggests
> font path issues.  I believe there's been a system upgrade since the
> last successful logins, which may account for the changes.
> 
> 
> I'm considering a few options for further diagnostic:
> 
>   - Network traffic sniffing:  watching communications to the kdm / vnc
>     server.  Since the traffic _should_ be localhost, I'm pretty
>     confident there are no firewall issues involved.
> 
>   - Using a different X display manager.  This idea didn't occur to me
>     until leaving the lab (won't be back until Monday) but might be
>     useful.


OK, it's working.

It was the IP address.

Literally:  at 10.9.12.53 (the assigned DHCP lease), the configuration
didn't work.

First thinking that networking was involved somehow, I tried downing the
external interface (eth0).  Everything worked (well, modulo remote
access).  Localhost testing via console (X -query localhost) and Xnest
(Xnest :1 -query localhost) both produced X sessions and [KWX]DM login
screens.

It took a while longer to consider trying an alternate _external_ IP
address.  First I used a 192.168-net address (not to interfere with any
existing LAN traffic), manually assigned.  Everything worked, including
remote access.

Then I tried an alternate (and unused) 10-net address, manually
assigned.  Ditto.

Then I tried manually assigning the same address that _didn't_ work, to
rule out any possible DHCP server configurations.  Failure.

Yeah, yeah, you're saying, someone had the same IP assigned elsewhere on
the net.

Well, if that's the case, neither ping nor nmap, from an alternate
address, picked up any sign of it.


My current workaround is to redefine the NIC as static, at its old
address.  I'll request a static IP assignment from the network
administrator tomorrow.

Strange happenings, though.  Thanks to all for their suggestions.



Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    * simonrvn is reading the top 100 on bash.org
    < gravity> Heh... I did that the other day
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.svlug.org/archives/svlug/attachments/20050405/1de277d7/attachment.bin


More information about the svlug mailing list