HP3000-L Archives

April 2000, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Bixby <[log in to unmask]>
Reply To:
Mark Bixby <[log in to unmask]>
Date:
Wed, 5 Apr 2000 09:31:39 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
Adrian Partridge wrote:
> >>>ping
> Name or Address of destination:WWW.GAINSBOROUGH.COM
> Sending -----------------------------------------
> 5 packets of 64 bytes to WWW.GAINSBOROUGH.COM
> ------------------------------------------
>
> ***(ERROR 134-228)Error getting IP address

Well, at least it's consistent.  The MPE resolver routines cannot resolve this
name, while the BIND resolver routines in nslookup can.

Are you able to use telnet or ftp or nettool to resolve *any* DNS names besides
the gainsborough machine (and the tower name)?

Did this ever used to work, or has it always been broken?

Because the MPE resolver routines can be affected by your :NMMGR configuration,
I suspect something is configured wrong or broken in NMMGR.

I tried playing with :NMMGR on my own machine to see if I could force a similar
problem.  I added a hostname to the NS Directory and gave it an IP address
different from what's in DNS.  I then went to the NETXPORT.GLOBAL screen and
changed the name search order to 1 0 0. The ftp client still uses the DNS
address, but nettool/ping uses the bogus NS Directory address.

While I wasn't able to break ftp by messing with :NMMGR, I'm wondering if
somehow you've found a way.  ;-)

It might be time for you to open an HPRC support call and talk to the MPE
networking experts....

- Mark B.

ATOM RSS1 RSS2