Hello Everyone,
Thanks to the following people for the quick and accurate response:
Alan: aareichert@tasc.com
John Clinton: jclinton@fridge.ccci.com
Ray Saddler: rsaddler@cccis.com
Their replies and the original question is posted below.
What has worked, thanks to the suggestions, is to add the IP addresses
of the NT machines in the /etc/hosts file. John Clinton gave useful
information, see below, as to what the
"read-rfc1918-for-details.iana.net" message means. I think the problem
was that as the Sun box was a DNS client to the DNS server which is on
the DMZ, it failed as 10.0.0.0 are in the private range. The sun box is
now configured to use the internal DNS server instead, i.e. the entry
in /etc/resolv.conf for external DNS server removed. I can now remove
the IP address of the NT machines from the /etc/hosts file and it will
still work.
Once again, thanks to everyone who replied.
Ramindur Singh
----------------- John Clinton ---------------
The replies I received were:
The IANA just recently (April 20, 1999 about 0600 EDT) made a DNS
change.
"read-rfc1918-for-details.iana.net" is now returned as a hostname when
reverse lookups are made to the private address space as defined in
rfc1918.
Prior to this to, reverse lookups would fail for private address space.
I think you mentioned you are using the 10.x.x.x network.
Now, as for your problem, the SUN box is doing a reverse lookup to
verify
who the NT box is when you are trying to fire up a dt login. Somewhere
in
the configuration on the SUN box is a setting of how to handle reverse
lookups. I wish I could tell where this is.
However, the proper way to fix this is to have your 10.x.x.x network be
delegated for forward and reverse lookups to your own name servers (not
the
Internet root servers). By configuring the reverse lookups to fail for
the
NT box it will likely permit your dt session to run properly.
Hope this helps.
Regards,
John
------------------ Alan ----------
I've run into similar problems. Make sure the Sun box knows the route
back to the NT machines. Check /etc/hosts for machine/IP entries.
- Alan
----------------- Ray Saddler -------------
I'm using an NT workstation with Exceed 5.1.3.0, getting my XDM from
a Solaris 7 box
I did the [full] install (not upgrade) of Solaris 7, with no special
modifications.
The exceed was also installed by me, with nothing in the way of generic
installation.
My configuration for communication is set to use XDMCP-query, display
number '0', to a host (by name, so dns is consulted) and the Display
Class is HCLpcXserver.
I guess that's about it!
I'll be glad to compare notes and system processes with you as necessary
to resolve your problem!
- Ray
------------- The Original Question ----------
have got a problem with getting dt login screen being displayed on NT
machines.
The setup is a Sun box running Solaris 7 and Windows NT with
Hummingbird's Exceed V6.0.
The configuration of Exceed is that it is set up for XDMCP-Query
pointing to the Sun machine. The screen definition is for a single
screen. In the past, that is few days ago, if the user started Exceed
on his PC, he got a DT login screen as you would do on the console.
Now, all that happens is that is that he gets a blank screen with an X
for the mouse, but no login screen. In the /var/dt/Xerrors I get a
message:
Wed Apr 21 12:51:27 1999
error (pid 906): Server open attempt #0 failed for
read-rfc1918-for-details.iana.net:0, giving up
The above message refers to RFC1918 which talks about private IP
address, of which we use 10.0.0.0 range, but I cannot see why or how
this is linked.
If I configure Exceed for Passive mode instead of XDMCP, multiple
screen, I can get, for example, xterm without any problem. I am also
able to start other applications and get them to display on their NT
machines.
I have checked /usr/dt/config and /etc/dt to make sure that no files
have been changed, restarted the dtlogin, but to no avail. I have not
been able to find anything related to this in the archives or the FAQ.
I believe that the problem is on the Sun machine, as all NT machines
have this problem with this particular Sun box, but not with other Sun
or HP boxes.
Has anybody had experience similar to this? Any ideas as to what could
have changed to cause this problem? I would greatly appreciate any
advice/suggestions and will summarize. TIA.
Regards,
Ramindur Singh
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:18 CDT