FTP login screen not appearing

[stuartl]

I have a DS10 system that I'm struggling with - I cannot get the FTP login screen to appear when I try to ftp to it remotely from a PC.  All I get it:

                           Connected to 172.28.32.xxx

and after 30 seconds or so I get:

                          Connection closed by remote host.

I never get the login screen to appear.

The DS10 (TRU52 V5.1a) is on 172.28.32.xxx  (netmask 255.255.255.128, gateway 172.28.32.129) and the PC is on 172.28.33.xxx (netmark 255.255.255.0 gateway 172.28.33.xxx). 

I also have an AS800 (Tru64 V4.0) which is on 172.28.32.xxx (netmask 255.255.255.128, gateway 172.28.32.129) and I can ftp to it from the PC without any problem.

I can ftp to the DS10 from the AS800 so I'm wondering if there is something I haven't get set properly in the network config of the DS10? 

Here's the contents of rc.config, anyone see anything in here that's not correct or suggest where my problem might be?

Thanks, Stuart

. /etc/rc.config.common
#
#
DISPLAYTYPE=
NETDEV_3=
NETDEV_4=
NETDEV_5=
NETDEV_6=
NETDEV_7=
IFCONFIG_3=
IFCONFIG_4=
IFCONFIG_5=
IFCONFIG_6=
IFCONFIG_7=
PAGEMINSZ=0
PAGEMAXSZ=0
COLLECT_AUTORUN="0"
COLLECT_COMPRESSION="1"
COLLECT_ARGS=
export DISPLAYTYPE HOSTNAME NUM_NETCONFIG
export NETDEV_0 NETDEV_1 NETDEV_2 NETDEV_3 NETDEV_4 NETDEV_5 NETDEV_6 NETDEV_7
export IFCONFIG_0 IFCONFIG_1 IFCONFIG_2 IFCONFIG_3 IFCONFIG_4 IFCONFIG_5
export IFCONFIG_6 IFCONFIG_7 RWHOD ROUTED ROUTED_FLAGS GATED GATED_FLAGS
export ROUTER MAX_NETDEVS COLLECT_AUTORUN COLLECT_COMPRESSION COLLECT_ARGS
export PAGERAW PAGEFILE PARTITION PARTITIONTYPE PAGEMINSZ PAGEMAXSZ
PAGERAW="1"
export PAGERAW
LAT_SETUP="1"
export LAT_SETUP
ENVMON_CONFIGURED="1"
export ENVMON_CONFIGURED
ARMTECH="yes"
export ARMTECH
ARMTMODS="ARMTcpu"
export ARMTMODS
ARMTDAEMON="yes"
export ARMTDAEMON
PAGEFILE="/dev/disk/dsk0b"
export PAGEFILE
PARTITION="dsk0b"
export PARTITION
PARTITIONTYPE="BD03685A24"
export PARTITIONTYPE
ENVMON_HIGH_THRESH="45"
export ENVMON_HIGH_THRESH
XLOGIN="cde"
export XLOGIN
NETDEV_2="bcm0"
export NETDEV_2
IFCONFIG_2="155.47.12.xxx netmask 255.255.0.0"
export IFCONFIG_2
NETDEV_1="ee1"
export NETDEV_1
IFCONFIG_1="DYNAMIC netmask 255.255.255.0"
export IFCONFIG_1
MAX_NETDEVS="24"
export MAX_NETDEVS
HOSTNAME="abc.corp.xyz.org"
export HOSTNAME
GATED_OLD="no"
export GATED_OLD
GATED="no"
export GATED
GATED_FLAGS=""
export GATED_FLAGS
ROUTED="no"
export ROUTED
ROUTED_FLAGS=""
export ROUTED_FLAGS
ROUTER="no"
export ROUTER
RWHOD="no"
export RWHOD
RWHOD_FLAGS=""
export RWHOD_FLAGS
NETDEV_0="ee0"
export NETDEV_0
IFCONFIG_0="172.28.32.xxx netmask 255.255.255.128"
export IFCONFIG_0
NUM_NETCONFIG="1"
export NUM_NETCONFIG

[Steven Schweda]

> The DS10 (TRU52 V5.1a) is on 172.28.32.xxx  (netmask 255.255.255.128,
> [...]

   "172.28.x.y" is a private address.  There's no benefit to hiding
details in such an address.  The penalty is that, with my weak psychic
powers, I can't tell if "xxx" is less than 128, so I can't tell which
subnet it's on.

   Is FTP the only service with the problem, or does it affect
everything (SSH, Telnet, "ping", ...)?

   Based on not much useful info, if it's an all-service problem, then
my first guess would be that one of these systems doesn't have a good
route to the other.  Messages can go one way, but responses can't find
their way back.  "traceroute" might be useful.  "netstat -rn" reports,
too.

   If it's an FTP-only problem, then I'd look for clues in the system
logs.

[stuartl]

Apologies for the lack of information, as you may be able to tell I am not overly familiar with this stuff but it's being left to me to try  and support it.

The address of the DS10 is 172.28.32.158, the pc is 172.28.33.30

I can ping the DS10 from the PC. 

I can log on to the DS10 from the PC using eXcursion (an old DEC tool) but it takes maybe 40 seconds or so to connect - I initially  get an error message saying the remote system did not reply to startup request within 30 seconds but then it connects.

'netstat -rn' gives the following:

root@SALMON> netstat -rn
Routing tables
Destination          Gateway          Flags        Refs      Use       Interface

Route Tree for Protocol Family 26:

Route Tree for Protocol Family 2:
default                 172.28.32.129    UGS            1        9319        ee0
127.0.0.1                127.0.0.1             UHL           9       94399       lo0
172.28.32.128/25   172.28.32.158     U               1              1         ee0
172.28.32.158        172.28.32.158     UHL          4           115        ee0
root@SALMON>

Any help greatly appeciated.

[Steven Schweda · Accepted solution]

> [...] but it takes maybe 40 seconds or so to connect [...]

   A pause of about 30s when first connecting suggests a fairly common
problem.  Many server programs do a reverse DNS look-up
(address-to-name) of a client when its connects.  If your DNS server
doesn't respond promptly to such a request, then you get a delay in the
connection.  The test is, on the _server_ system:

      nslookup <client_IP_address>

   Note that specifying the server's IP address in the client does not
help.  The problem is on the server side, when it tries to get the name
of the client from its address.

   If that reverse DNS look-up is slow or fails, then you might want to
see what's in "/etc/resolv.conf", which is where I'd expect the DNS
server(s) to be specified ("nameserver a.b.c.d").

   I'm not sure that a 30s (or so) DNS delay would be enough to
completely disable the FTP server, so there could also be some
FTP-specific problem(s).

> I can ping the DS10 from the PC.

> root@SALMON> netstat -rn
> [...]

   That all looks plausible, and the "ping" success suggests that it's
not a routing problem.

[stuartl]

Steven, you are a ***STAR*** and go to the top of the class :)

resolv.conf had the wrong info in it, pointing to an old server so I put in the new details and it works, eXcursion connects in about 1 second and ftp login appears!!!!

Thank you so much for your help.

[Steven Schweda]

> resolv.conf had the wrong info in it, pointing to an old server so I
> put in the new details and it works, [...]

   What could go wrong?

   As I said, it's a fairly common problem.  Although I don't recall
previous complaints about FTP, a Forum or Web search for keywords like
"slow ssh" or "slow telnet" should find abundant examples.  The key is
recognizing that it's a one-time delay when the connection is made, not
a general slowness which persists.  Then, understanding who is trying to
look up what.

> Thank you so much for your help.

   Thanks for the update.  Glad to hear that you got it sorted.