Ftp connectivity between two UNIX servers

Hi All

I am having issues using ftp between a solaris 10 server to a HP-UX 11.31 server, but from the solaris server to the hp-ux I am able to ping. This is what I have done so far:
in the solaris server:

root@MPCRS01 # svcs -a | grep ftp
online         Jul_26   svc:/network/ftp:default

and

svcs -xv ftp
svc:/network/ftp:default (FTP server)
State: online since Fri Jul 26 19:48:55 2013
See: man -M /usr/share/man -s 1M in.ftpd
See: man -M /usr/share/man -s 1M ftpd
Impact: None.

and

# cat /etc/services |grep -i ftp
ftp-data        20/tcp
ftp             21/tcp
tftp            69/udp

and

# netstat -an |grep -i *.21
*.21                 *.*                0      0 49152      0 LISTEN
*.21                              *.*                             0      0 49152      0 LISTEN

and

 # netstat -nr
  
  Routing Table: IPv4
    Destination           Gateway           Flags  Ref     Use     Interface
  -------------------- -------------------- ----- ----- ---------- ---------
  default              10.254.3.65          UG        1     107127
  10.254.3.64          10.254.3.69          U         1        173 nxge0
  224.0.0.0            10.254.3.69          U         1          0 nxge0
  127.0.0.1            127.0.0.1            UH      632   28972624 lo0
  root@MPCRS01 # ifconfig -a
  lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
          inet 127.0.0.1 netmask ff000000
  nxge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
          inet 10.254.3.69 netmask ffffffc0 broadcast 10.254.3.127
          ether 0:21:28:b1:db:70
  

Sorry I had to copy and paste from email sent to me with those comands as I do not have access to the system.

On the HP-UX server:

 #cat /etc/inetd.conf | grep ftp
ftp          stream tcp6 nowait root /usr/lbin/ftpd     ftpd -l
#netstat -an |grep -i *.21
tcp        0      0  *.2121                 *.*                     LISTEN
tcp        0      0  *.21                   *.*                     LISTEN
cat /etc/services |grep -i ftp
ftp-data      20/tcp                 # File Transfer Protocol (Data)
ftp           21/tcp                 # File Transfer Protocol (Control)

Please can you assist

---------- Post updated at 02:55 PM ---------- Previous update was at 09:53 AM ----------

I try to connect from the solaris 10 server, using

sftp root@10.1.20.33

and on hp-ux server I have run the following:

/usr/local/sbin/tcpdump -v host 10.254.3.69

and the output was:

tcpdump: listening on lan2, link-type EN10MB (Ethernet), capture size 65535 bytes
14:31:16.479520 IP (tos 0x0, ttl 62, id 52233, offset 0, flags [DF], proto TCP (6), length 52)
    crs.58105 > mcelVMhost5.22: Flags , cksum 0x91b3 (correct), seq 2968345370, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
14:31:16.522288 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has crs (Broadcast) tell mcelVMhost5, length 28
14:31:16.543097 ARP, Ethernet (len 6), IPv4 (len 4), Reply crs is-at 58:8d:09:a1:ee:21 (oui Unknown), length 46
14:31:16.543137 IP (tos 0x0, ttl 64, id 8869, offset 0, flags [DF], proto TCP (6), length 52)
    mcelVMhost5.22 > crs.58105: Flags [S.], cksum 0x2c8b (incorrect -> 0xa433), seq 570920015, ack 2968345371, win 65535, options [mss 1460,nop,nop,sackOK,wscale 2,nop], length 0
14:31:17.604979 IP (tos 0x0, ttl 62, id 52234, offset 0, flags [DF], proto TCP (6), length 52)
    crs.58105 > mcelVMhost5.22: Flags , cksum 0x91b3 (correct), seq 2968345370, win 49640, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
14:31:17.605304 IP (tos 0x0, ttl 64, id 8870, offset 0, flags [DF], proto TCP (6), length 52)
    mcelVMhost5.22 > crs.58105: Flags [S.], cksum 0x2c8b (incorrect -> 0xa433), seq 570920015, ack 2968345371, win 65535, options [mss 1460,nop,nop,sackOK,wscale 2,nop], length 0

Please can someone explain?

sftp is really ssh/scp not ftp (except to the command interface). Do you want ftp? Does ssh work?

Hi

I want ftp

Try ftp 10.1.20.33 if you want to ftp, or get the SSH server running on 10.1.20.33 if you want to sftp.

Robin

Hi!

I am able to ftp 10.1.20.33 from most servers, only for one particularly, I cannot. ssh is already running on 10.1.20.33, because I am able to connect usinh ssh from any server.

So, on the server you are trying to connect to, can you run:-

netstat -na|egrep "[.:]2[12] " | grep LISTEN

This should tell use what you have running. Please paste it inside CODE tags.

If port 21 is listening, then you can FTP. If it's port 22 then it's SSH/SFTP.

If your chosen tool is being listened for but it is not connecting, what symptoms do you get? It's probably either:-

  • About a 30 second delay then a time-out message - suspect firewall
  • Immediate connection refused message - suspect a mis-configured service

If you get something else, let us know and we can have another think.

Robin

Hi !

I have port

21

listen, not a problem, the strange thing is that that same server, in which I am trying to ftp, can ftp successfully to another server, on the same chassis that resides the other server that refuses to accept ftp.

And what are the symptoms/messages?

From the server that I want to ftp I just type :

# ftp 10.1.20.33

and nothing happens, but if

ftp

to a different server on same chassis like:

# ftp 10.1.20.31
Connected to 10.1.20.31.
220 mcelVMhost3 FTP server (Revision 6.0 Version wuftpd-2.6.1 Fri Apr  1 07:44:09 GMT 2011) ready.
Name (10.1.20.31:root): root
331 Password required for root.
Password:
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

it works

Now if I even change source server like from

10.100.48.73

try to ftp to the server that is refusing to accept ftp sessions:

# ftp 10.1.20.33
Connected to 10.1.20.33.
220 mcelVMhost5 FTP server (Revision 6.0 Version wuftpd-2.6.1 Fri Apr  1 07:44:09 GMT 2011) ready.
Name (10.1.20.33:root): root
331 Password required for root.
Password:
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bye
221-You have transferred 0 bytes in 0 files.
221-Total traffic for this session was 274 bytes in 0 transfers.
221-Thank you for using the FTP service on mcelVMhost5.
221 Goodbye.

it works fine as well

So no response even in five minutes?

Still looks like a firewall issue to me. Can you telnet to a few things:-

telnet 10.1.20.33                    # Simple telnet
telnet 10.1.20.33 21                 # FTP port
telnet 10.1.20.33 25                 # SMTP, just as a test
telnet 10.1.20.33 123                # Hit the time server
telnet 10.1.20.33 99999              # Pick a port that should not respond

They should either connect or fail. Try pressing ENTER a few times. You can monitor their success from another session with netstat -na | grep 10.1.20.33 21 to see if the session is established.

Some may never connect, but you should wait at least 60 seconds before cancelling them.

What do you get?

If you are running Linux on either side, are you also using SELinux? That is know for odd errors unless you get it right, and i don't know how.

Robin

Could be firewall/iptables on that client or on the route in. Try ping 10.1.20.33, traceroute 10.1.20.33, telnet 10.1.20.33 21 from that client host.

Hi

we�ve not solved yet, the network team are saying that no restrictions were imposed on traffic between those two servers, so they are alledging that may be the routing table on the destination server is wrong, but I cant spot anything wrong on it:

#netstat -nrv
Routing tables
Dest/Netmask                    Gateway            Flags Refs Interface  Pmtu
127.0.0.1/255.255.255.255       127.0.0.1          UH    0    lo0       32808
10.1.20.33/255.255.255.255      10.1.20.33         UH    0    lan2      32808
10.0.0.0/255.0.0.0              10.1.20.33         U     2    lan2       1500
10.100.0.0/255.255.0.0          10.1.20.100        UG    0    lan2       1500
127.0.0.0/255.0.0.0             127.0.0.1          U     0    lo0       32808
192.168.0.0/255.255.254.0       10.1.20.100        UG    0    lan2       1500
default/0.0.0.0                 10.1.20.1          UG    0    lan2       1500

It seems odd that you have a 24 bit lan aove an 16 bit lan (10.*.*.* over 10.100.*.*).

Traceroute in each direction should show you the routing out and back. However, if routing is bad, ping should fail.