VMS ftp issues

[Ben Bramwell]

Okay I've been searching around on the net and found this page http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=642790 which describes my problem exactly and a solution. Problem is I've added the server to the local host file and I'm still getting the same problem.

%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%UCX-I-FTP_SESCON, FTPD: Session connection from corpapp.XXX at 25-OCT-2005 11:45:30.71

I don't understand how it can't resolve the name for several attempts and then it just starts working again if it's in the local host file. The server is pointing at a windows DNS server for DNS resolution but it shouldn't even contact the DNS server since it's in the local host, right? Any help would be greatly appriciated.

[Steven Schweda · Accepted solution]

As usual, it might help to know what "UCX
SHOW VERSION" reports.

Can I assume that those messages are from the
FTP server log?

With my:

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2,

I see only IP addresses in the
%TCPIP-I-FTP_SESCON messages, and I don't get
any FTP_GETHST messages. It's not clear
which host of yours it can't find, either.

Is there an FTP server option to suppress the
host name look-up? I seem to have:

(LNM$SYSTEM_TABLE)
"TCPIP$FTP_SERVER_LOG_CLIENT_BY_ADDRESS" = "TRUE"

This could explain something.

Where/what is your FTP client? Can you get
a better result if you FTP from the VMS
system to itself?

[Arch_Muthiah]

Hi Ben,

Look into host files of your Window and VMS, both should have entry for each other host and ip address.

Edit Window host file and add vms host name and IP,
the same way in the VMS side,
$TCPIP
TCPIP> show host -- list all the hosts, make sure your window host and its IP address are there. if not,

TCPIP> SET HOST wind_hostname /addres=win_ip
TCPIP> show host -- make sure wind host/ip address are there.

Are these wind and VMS in the same subnet?

Archunan

[Ben Bramwell]

Steven:
I think I win for old versions =P
Digital TCP/IP Services for OpenVMS Alpha Version v4.2 on a alphaserver 2100 4/275 running Open VMS v6.2-1h3

Yes those are the ftp server logs.

I was actually considering turning off this reverse dns lookup as an option but I have no experience with VMS and pretty much know very little about it. If you could explain how this might be done it would be greatly appriciated.

It happens from any client I've tried. Windows ftp, warftp, and a custom ftp program we use for EDI transactions (this is what we are really having the problems with).

I have not tried ftping from VMS to itself and the next time this problem occurs I will attempt to do that.

Archunan:
The VMS server has the entries for this particular host in the host file. We don't use host files on our windows system just the DNS servers and they have never had a problem with resolving the name of the VMS server. They are on different subnets.
Also this problem happens identically for servers that are in the host file and servers that aren't.

This problem seems to be completely random. It will work for sometime and then all of a sudden it stops work then about 3-5 minutes later it is working again. I have monitors on a windows box polling the DNS server ever minute and it has never failed so I don't think the issue lies there.

[Steven Schweda]

The only pre-TCPIP UCX I ever really used was
an evaluation copy of about V1.3, as I
recall, and it was dreadfully short on
features, so we chose Wollongong WIN/TCP
instead. (Now, that's old.)

Yes, DNS should be enough. The UCX HOSTS
data base should normally contain only
enough to get going.

If the DNS resolver on the Alpha is hosed,
perhaps "UCX SHOW NAME" will say something
suggestive. As usual, bad routes or bad
hardware could screw things up, too.

If your UCX has a thing like my TCPIP's
TCPIP$FTP_SERVER_LOG_CLIENT_BY_ADDRESS, then
it's a system logical name, and it's set
using a command somewhere in the start-up
procedures. Something like:

$ define /system /executive_mode TCPIP$FTP_SERVER_LOG_CLIENT_BY_ADDRESS "TRUE"

I have this logical name definition in a
SYS$MANAGER:LOGICAL_NAMES_LOCAL.COM, which
gets done ("@") somewhere inside
SYS$MANAGER:SYSTARTUP_VMS.COM, but it
probably doesn't matter much where/when it
gets done. Yours, if it works at all, would
be UCX$blah instead of TCPIP$blah, of course.
Whether that was a feature back then, I know
not, however, and, in any case, if the
reverse name look-up should work, then it
should work, irregardful.

[Ben Bramwell]

UCX SHOW NAME shows everything how it should be =(. The name of the server that is having problems connecting is in there with it's correct IP address. Like you mentioned though it doesn't actually telling me what record it's trying to lookup when it's getting the error. Just the way the log file is formatted it's suggesting to me that it's this server.

It would be nice to resolve whatever dns issue I'm having but for the time I'm going to attempt to get it to stop doing the reverse lookups. Thanks for the info

[Steven Schweda]

The FTP server would (should?) be trying to
look up the IP address of the client which
is connecting. The question is less if the
DNS server exists than if it is doing (and
promptly) a (reverse) look-up of the FTP
client's IP address.

For convenience, you should have a UCX-like
version of a symbol like this defined:

NSL*OOKUP == "$ SYS$SYSTEM:TCPIP$NSLOOKUP.EXE"

You should be able to feed the IP address of
the FTP client into nslookup, and get a
snappy response:

ALP $ nslookup 10.0.0.37
Server: alp-l.antinode.org
Address: 10.0.0.9

Name: ung.antinode.org
Address: 10.0.0.37

That's approximately what the FTP server is
trying to do to get the client's name for
the log file. (All your data will be
different, of course.) With the right DNS
server problems, it's easily possible for
name-to-address look-ups to work, but for
address-to-name look-ups to fail.

[Ben Bramwell]

But even if there are DNS issues shouldn't it always look at the host file first? Since it's in the host file it shouldn't even be bothering the DNS server.

Thanks for pointing out the nslookup command on there. I've used it in windows a lot but when I'm at the UCX prompt it doesn't show up under help, had to be at the $ prompt to see it.

Right now it's all working fine but I will wait for a problem to occur with the ftp and try the nslookup then.

Also if anyone could ponit out a way to turn this reverse dns lookup off with the version I'm running. I spent about 2 hours yesterday searching the net and couldn't find any way to do it. Thanks

[Steven Schweda]

A Google search for
FTP_SERVER_LOG_CLIENT_BY_ADDRESS
found a (broken) link to:
http://h71000.www7.hp.com/doc/tcpip51/documentation/v51_relnotes_007.html
which makes it look as if it was new in V5.1
(TCPIP). Newer docs also suggest:
TCPIP$FTP_SERVER_NAME_SERVICE_RETRY
TCPIP$FTP_SERVER_NAME_SERVICE_TIMEOUT
which you probably don't have, either.

Searching the HP site was, of course,
useless.

The (newer) manuals do say things like:

When a request for name translation arrives,
the resolver first searches the local host
database for the host information. If the
information is not found, the resolver then
queries the BIND name server for host
information.

Not that I don't trust you (which I don't,
of course, "Trust no one" being my motto),
but so far I believe that we have only your
word that the FTP client host data are in
the UCX HOSTS data base. I see no real
names or addresses (other than mine), and no
UCX SHOW HOSTS /LOCAL output.

[Ben Bramwell]

Okay so here's some data for you

FTP Log file:
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%UCX-I-FTP_SESCON, FTPD: Session connection from corpapp.nacscorp.com at 25-OCT-2005 19:56:18.90

%UCX-I-FTP_USER, Username : FTPDATA
%UCX-I-FTP_SESDCN, FTPD: Session disconnection from corpapp.nacscorp.com at 25-OCT-2005 19:57:34.50

%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%UCX-I-FTP_SESCON, FTPD: Session connection from corpapp.nacscorp.com at 25-OCT-2005 20:05:31.12

%UCX-I-FTP_USER, Username : FTPDATA
%UCX-I-FTP_SESDCN, FTPD: Session disconnection from corpapp.nacscorp.com at 25-OCT-2005 20:05:33.28

%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%RMS-E-RNF, record not found
%UCX-E-FTP_GETHST, Error in getting host name
%UCX-I-FTP_SESCON, FTPD: Session connection from corpapp.nacscorp.com at 25-OCT-2005 20:18:30.99


Local host file:
UCX> show host /local

LOCAL database

Host address Host name

172.16.2.6 CORPAPP
172.16.2.5 CORPEXCH
206.216.64.200 CORPMIS01
172.16.3.10 CORPWH01
206.216.64.123 CORPWK123
172.16.2.240 LATTIS
127.0.0.1 LOCALHOST, localhost
206.216.64.2 NACS01
206.216.64.18 NACS02, nacs02
206.216.63.29 NACSFNP2
206.216.62.11 NACSINC1
206.216.65.2 NACSINC2
206.216.65.3 NACSINC3
206.216.64.22 OEPRINTER
206.216.64.82 PUBNET
206.216.64.67 RAPSTN
206.216.64.80 ROUTER
206.216.64.116 SERV1
206.216.64.115 SERV10
206.216.64.117 SERV2
206.216.64.118 SERV3
206.216.64.119 SERV4
206.216.64.110 SERV5
206.216.64.111 SERV6
206.216.64.112 SERV7
206.216.64.113 SERV8
206.216.64.114 SERV9
206.216.64.90 SYN001
206.216.64.91 SYN002
206.216.64.92 SYN003


Realize that the local host use to have corpapp.nacscorp.com when the ftp log file you see was generated. I changed it to corapp in the hopes of fixing this.

Let me know if you see something that is wrong. Thanks

[Steven Schweda]

Those data look plausible enough, assuming
that the domain is set to "nacscorp.com" for
the resolver (UCX SHOW NAME).

In desperation, you could have both the
fully qualified name and the basic name in
there, although that should not be necessary.
(UCX SET HOST /ALIAS)

Another desperation move would be to try both
upper- and lower-case. (Use: "name". Hosts
and resolver domain.) I seem to have both
"alp" and "ALP" in my HOSTS data, although
that may be entirely accidental. It
shouldn't matter, of course.

It's starting to sound more like a bug,
although the recommended fix is likely to be
an upgrade. The variable number of
FTP_GETHST errors is a bad sign on the DNS
front, I'd say.

I'd bet this'll be interesting if you ever
figure it out.

[Steven Schweda]

Re: Case.

Note that we both have both "LOCALHOST" and
"localhost", and I know that _I_ had nothing
to do with setting that one. Not that it
should matter, ...

[Ben Bramwell]

Okay I set both CORPAPP and CORPAPP.NACSCORP.COM to the IP

I attempted to get it in there lower case but couldn't.

I tried:
UCX> set host corpapp /address=X.X.X.X /alias=CORPAPP
%UCX-E-HOSTERROR, Error processing HOST request
-UCX-E-DUPHOST, Duplicate UCX$HOST entry for CORPAPP


I'm probably doing something wrong here.

I figured an upgrade might be what is needed to fix the issue but that's not a possibility at the present time. We will be implementing all new hardware in the next 6 months I believe and when that happens the software will also get upgraded. This problem I think has always existed but it has recently been causing more problems so I was hoping to fix it until the new hardware was installed.

[Ben Bramwell]

Just wanted to let you known that after these modifications it still happened. Also while it is happening I can't even ftp to localhost or the nacs01.nacscorp.com (the server name) from the server itself. It gives me

%FTP-E-NETERR, I/O error on network device
-SYSTEM-F-TIMEOUT, device timeout

[Jan van den Ende]

Ben,


I attempted to get it in there lower case but couldn't.
set host corpapp /address=X.X.X.X /alias=CORPAPP


If you leave the /addr= out of that, THEN you will create an alias.
And if you want it lowercase also,
UCX> set host x.x.x.x /alias ="corpapp"
(between double quotation marks).
For the second (and any subsequent) alias, you will get in -I- message, that looks remarkably like an error, but IS only informational.

Success.

Proost.

Have one on me.

jpe