Reflection and XDMCP Broadcast takes long time connecting

[Mohamed K Ahmed]

All,
Here is the situation. I have 5 ES40's runing Tru64 Unix V5.1 and 5.1B updated to latest patches.
The network admin rebooted the network hubs, switches..etc last weekend and since then the WRQ Reflection X software request from the desktops to the servers takes about 1 minute to connect. This process used to take less that a second. XDM uses ports 117/UDP and 6000/TCP and both are open.

The WRQ Reflection X running on the desktops send an XDMCP message to all servers running XDM (my unix servers), the servers respond with the dt login screen. I have cheched the Xerrors file and found a message saying that "Unable to convert xx.xxx.xxx.xxx IP to a host name"
When I put the IP and desktop name in the /etc/hosts file it works very good as before. I have checked the /etc/resolv.conf file, it has domain and 2 nameservers for our DNS servers. I have added the DNS servers to the /etc/hosts file.

What could be the problem, any one saw this before?

I am thinking that there is something in the network that is preventing XDMCP messages and/or reverse DNS lookup, the network admin told me all is fine.

Any suggestions?

[kmcgrath]

One thing to look at is if you have a firewall installed anywhere in your path then make sure the firewall rules haven't been modified or disabled.

[Mohamed K Ahmed]

The firewall was checked and nothing have been changed on it.

[Mobeen_1]

Mohammed,
Without reading your complete post, half-way i was just about to mention to you to go ahead add the IP addresses in /etc/hosts file and try...but you have already done that and confirmed that its working fine.

So this tells me that somethings changed on your DNS servers? Could you find out if anything has changed on your DNS?

By putting in entries in /etc/hosts file, whats essentially happening is we are by passing the DNS to some extent...

regards
Mobeen

[Al Licause]

In the original problem statement, you state that it takes about a minute for
the connection to complete, whereas, prior to the network changes, it took
about a second.

This would correspond to a dns query timeout. Since it eventually succeeds,
it appears that either a timeout is occuring when attempting to reach the
primary dns server ( the first one listed in resolv.conf ) and then possibly
getting a successfuly reply from the second, or it fails to get any dns reply
and the application is simply letting the connection proceed.

The message in the log file is telling us exactly what the problem is....
i.e., we are unable back translate the incoming ip address to a hostname.

But now you need to find out which dns server is no longer responding or if
anything has changed on that dns server.

You could try running nslookup on that ip address to see if the first server
in your list responds correctly. If it doesn't point to the 2nd server in
the list and try again.

Or you could use tcpdump to trace port 53 and see who is responding.

[Mobeen_1]

Mohamed,
Whats happened to this ? Have you managed to sort this out ? As i told you and per the previous suggestion, perform nslookup and see for both the DNS servers, it pretty much looks like an issue in the DNS arena

rgds
Mobeen

[Mohamed K Ahmed]

OK, here is what I have till now.
Strangely enough and after cheking the resolv.conf and the hosts file and as a last resort, I rebooted one of the systems that I have and after that everything worked as usual (for this one system).
I am scheduled to reboot the other systems on Saturday to resolve the problem.
What happened in the beginning is that we have rebooted the whole network environment and changed the IP address of the DNS servers. I didn't know that untill the next day, so I changed the dns servers names in the hosts files and the resolv.conf file. That when I saw the problem. I restarted nthe network services on all my systems and I thight it will take care of it, but it didn't. I thought that the changes will make instant effect, but I think I was wrong and a reboot had to be performed.
I will finalize on Monday

Regards,
Mohamed

[Mobeen_1]

Mohamed,
That probably explains it :)

rgds
Mobeen

[Mohamed K Ahmed]

h