Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1796
  • Last Modified:

SCO OpenServer 5.0.7 Slow FTP Connect

I know this question has been asked before but it was a while back and I could not resolve my problem by following what was said at the time.

I have installed 3 new SCO OpenServer 5.0.7 systems.  In all three instances I am having no problem with the telnet connect, but I am experiencing a 13-15 second delay connecting to ftp.  The last system I setup was purely for testing this problem.  It is a fresh install from the distribution with no maintenance.  There by default is no /etc/resolv.conf.  I created one as:

nameserver 10.0.0.1
nameserver 10.0.0.100
hostresorder local bind
search

These IP addresses are the two dns servers on our network.  

A netstat -nr yields:

Destination      Gateway            Flags    Refs      Use  Interface
default          10.0.0.100         UGS         0       17  net0
10               10.0.0.30          UC          1        0  net0
10.0.0.30        127.0.0.1          UGHS        4       26  lo0
127.0.0.1        127.0.0.1          UH          2      124  lo0

My ip address is 10.0.0.13 with a mask of 255.0.0.0

There has been no software installed at this time on this server.  It is just a bare bones fresh install.

Any thoughts will be appreciated.

Alan
0
alanmaul
Asked:
alanmaul
  • 6
  • 6
  • 5
  • +1
3 Solutions
 
yuzhCommented:
Please have a look at the answer in http:Q_20668120.html
0
 
yuzhCommented:
Also please check your DNS records in your DNS server are clean, a box A does not have two
record with two different IPs and only ONE NIC. (some time it does happen, one you machine
had pull down from the network, and later on someone decide to use the same machine with
a different IP and put it in the network).

use nslookup to check if you have DNS problem, also run ftp in debug mode "ftp -d" to see
what happen.
0
 
alanmaulAuthor Commented:
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
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
jlevieCommented:
That sounds like you Have a kerberized FTP server in a non-Kerberos environment. The delay is the result of the FTP server trying Kerberos authentication, which eventually fails. I'm sorry, but I don't know what you'd need to do on SCO to use a non-kerberized FTP server.  But figuring that out will fix the problem.

Maybe another expert knows what the fix is.
0
 
yuzhCommented:
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.
0
 
alanmaulAuthor Commented:
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.
0
 
jlevieCommented:
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.
0
 
jlevieCommented:
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
0
 
alanmaulAuthor Commented:
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.

0
 
jlevieCommented:
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.
0
 
gheistCommented:
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.
0
 
alanmaulAuthor Commented:
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?
0
 
jlevieCommented:
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.
0
 
yuzhCommented:
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
0
 
gheistCommented:
just give it all to dns guys and tell them to fix it fast ( usually ttl is 24h )
0
 
alanmaulAuthor Commented:
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.
0
 
gheistCommented:
You have to restart inetd after changing resolver config
0
 
alanmaulAuthor Commented:
I have rebooted the server after each change.
0
 
gheistCommented:
you have to use search domain.tld or no search, ndots:1 is redundant default, having no effect currently.


basically your nameserver must respond to two queryes for its IP address, client , server, probably every router in route and localhost/127.0.0.1

like these
dig -t A @nameserver-to-be localhost.domain.tld
dig -t PTR @nameserver-to-be 1.0.0.127.in-addr.arpa

there are some other DNS resource records, that you see by host command, but they are most likely unrealted unless you run electronic mail
0
 
gheistCommented:
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
0
 
gheistCommented:
Yuzh was first to recognize a problem with DNS, rest was tricking asker into fixing problem.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 6
  • 5
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now