SCO OpenServer 5.0.7 Slow FTP Connect

Please have a look at the answer in http:Q_20668120.html

My network folks checked the DNS Server and said it was fine.  I have to take their word for that.  

The three servers I have build are in three different locations on 3 different networks and are all experiencing the same problem.  I get the delay whether routing in from some other subnet or from workstations on the servers subnet.

I checked nslookup and it seems to respond just fine with appropriate addresses.

I tried ftp with the -d option. (I replace the ip addresses since for testing I had opened them up to the real world.)  The delay is right after I get the Connected to n.n.n.n.  The response are as follows:

# ftp -d n.n.n.n
Connected to n.n.n.n.
220-
220 scosysv FTP server (Version wu-2.6.2(1) Wed Jun 23 17:32:38 PDT 2004) ready.
---> AUTH KERBEROS_V5
530 Please login with USER and PASS.
Kerberos V5: rejected as an authentication type
Name (n.n.n.n:root):

Thanks for responding.  Still looking for ideas.

Alan

jlevie's comment make sense. I have not play with SCO for a long time now (I had only used
up to SCO 5.0.6).

try to use ftp with "-A" option,

eg: ftp -A ...
     ftp -Ad ...

see what happen.

jlevie

I think you are onto the problem.  Interesting though I find these statements in the man pages.

Man page for ftpd:

Limitations

   Kerberos Network Authentication Service protocol is no longer
   supported.

Man page for ftp:

Limitations

   Authentication is based on Version 5 of the Kerberos Network
   Authentication Service protocol. Only this version of the
   protocol is supported.

It appears to me that ftpd will no longer support kerbberos_v5 and ftp only supports kerberos_v5.  Is that what the man pages say, or am I missing something.


yuzh

This the the output from test with ftp -A

# ftp -Adv n.n.n.n
Connected to n.n.n.n.
220-
220 scosysv FTP server (Version wu-2.6.2(1) Wed Jun 23 17:32:38 PDT 2004) ready.
Name (n.n.n.n:root): root
---> USER root
331 Password required for root.
Password:
---> PASS XXXX
230 User root logged in.
---> SYST
215 UNIX Type: L8 (SCO OpenServer Release 3.2v5.0.7 of 2003-02-18)
Remote system type is UNIX.
---> TYPE I
200 Type set to I.
Using binary mode to transfer files.

While the -A parameter looked like it would change the authentication, it didn't appear to make any difference.

What happens if you use a Linux or windows FTP client to connect to the FTP server? Does it also show the delay in connecting? If it does it might be a reverse lookup problem where the FTP server is trying to do a reverse lookup on the client's IP. If the DNS doesn't have PTR data for that IP or isn't responding to in-addr.arpa queries it will cause a delay between the "Connected to..." and "Name" prompt.

If you have reason to believe that it is an in-addr.arpa lookup problem you can add a record to the FTP server's hosts file for the IP you are doing the test from. If that eliminates the delay you've found the cause of the problem.

For AUTH plain the client must send <authorize-ID\0authenticate-ID\0password\0> encoded in base64. For example:

>>> AUTH PLAIN dGVzdAB0ZXN0QHdpei5leGFtcGxlLmNvbQB0RXN0NDI=

decodes as:

test\000test@wiz.example.com\000tEst42

jlevie

I added an entry in the hosts table on the server for my workstation.  We are both on the same subnet.  Did not resolve the problem.  I don't think at this time it is a DNS issue.

I have tried to connect from windows using the Microsoft FTP Client and using FTP Voyager.  Same problem with both clients.

What I'd do at this point is to us a sniffer to watch all of the network traffic to/from the FTP server. From the timestamps you can tell what's happening and when.

To diagnose name lookup on server do:
host 10.0.0.13
and
host whatever.name.you.got

If no match then DNS is a problem.

qhiest

Thanks for the response.

These are the commands that I tried and the responses.

# host 10.0.0.49
Host not found.
# host www.lasere.com
www.lasere.com is a nickname for lasere.com
lasere.com has address 209.240.18.192
lasere.com mail is handled (pri=10) by lasere.com
lasere.com mail is handled (pri=20) by mail.lasere.com
# host lasere.com
lasere.com has address 209.240.18.192
lasere.com mail is handled (pri=10) by lasere.com
lasere.com mail is handled (pri=20) by mail.lasere.com
# host alantoshiba <== this is the workstation I am running on.
Host not found.
# host localhost
Host not found.
# cat hosts  <== Cat of my hosts file
#      @(#)hosts,v 6.1 1993/08/21 02:17:48 stevea Exp - STREAMware TCP/IP  sourc
e
#      SCCS IDENTIFICATION
127.0.0.1       localhost
10.0.0.1        dns
10.0.0.100      dns2
10.0.0.49       alantoshiba <==  My workstation
10.0.0.30       fwnco fwnco.fwnco.com <==  The server
# host fwnco.com
fwnco.com has address 10.0.0.1
fwnco.com has address 10.0.1.51
fwnco.com has address 223.1.1.128
# host www.fwnco.com
www.fwnco.com has address 64.132.40.19
# host dns
Host not found.
# host dns2
Host not found.
# host 127.0.0.1
1.0.0.127.IN-ADDR.ARPA domain name pointer localhost
# host 10.0.0.30  <== this is the IP of the server
Host not found.


Any thoughts about what to try next?

Those results pretty clealy show that reverse lookups don't work. On a Linux or Unix box that uses hosts then dns for name resolution adding the client IP/hostname to the hosts file avoids the timeout on an in-addr.arpa query by FTP. I don't know if SCO operates on the same rules, maybe some one else will know.

Now you need to ask your DNS guys again!

or just add your FTP client infor to your FTP server's /etc/hosts file.

also have a look at:
http://docsrv.sco.com:8457/en/scomsg_gs/gs_files/msggs.dns.html

just give it all to dns guys and tell them to fix it fast ( usually ttl is 24h )

In the sample data I included above, 10.0.0.30 is the SCO FTP server, and the 10.0.049 is my FTP client address.  They are both in the /etc/hosts file, and I still have the delay.  All of my FTP sessions are on local links.  They are on VPN but I know the address ranges of the segments and I have them in the routing tables so that Unix knows how to get back to the addresses.

You have to restart inetd after changing resolver config

I have rebooted the server after each change.

and btw show these commands to your DNS guys , to introduce reverse zone for private intranet.
on the other hand you can run bind dns server on your host if they do not cooperate for week or so

http://osr5doc.sco.com:457/cgi-bin/man/man?resolv.conf+SFF

Yuzh was first to recognize a problem with DNS, rest was tricking asker into fixing problem.