Greg asks:
> ftp>OPEN 67.122.120.33 2001
> 220 HP ARPA FTP Server [A0009O15] (C) Hewlett-Packard Co. 2000
> [PASV SUPPORT]
> Connected to 67.122.120.33. (FTPINFO 40)

> ftp> PASSIVE
> Passive mode is on.
> ftp> PUT /TFTP/PUB/FMEDI832 /EDIHS37/DATABASE/FMEDI832
> 227 Entering Passive Mode (192,1,1,111,200,34).
> UnKnown Socket Error.

Wild guess:

You're getting to the 3000 via an "outside" IP Address (67.122.120.33) which
passes through a firewall or gateway router that is performing Network
Address Translation to convert to the internal IP Address block used inside
your internal network.  On this internal network the 3000 has an IP Address
of 192.1.1.111.

In passive mode, the server sends a message to the client containing the IP
Address and Socket# that the client should connect to in order to perform
the data transfer.

In this case we see that the internal IP Address of the 3000 "leaked" to the
client which was then unable to connect to the server using the (externally
bogus unless you actually *are* Bolt Beranek and Newman) 192.1.1.111
address.

The way this is *supposed* to work is that the box performing the NAT will
magically see the IP address being sent to the client and "fix it" by
dynamically altering the packet to include the external address of the
target machine.  It's quite amazing that this works so well normally that
most people don't know that their NAT box is frantically rewriting packets
left and right so that the IP Addresses look correct to everyone involved,
even though each end normally doesn't know the "real" IP Address that they
are talking to.

But this fancy NAT stuff only works if the NAT implementation knows about
all the protocols that you are going to use that send embedded IP Addresses
in the data.

In your case there are several possibilities if this is the problem:

1) Your NAT implementation may be so simplistic that it doesn't support FTP
right.
2) The 3000's FTP server may be sending the PORT command back in some
unusual way that causes the NAT device to not see it (splitting the message
in two send() calls could result in two packets and this might break some
low-tech NAT implementations for example).
3) The 3000 FTP server might not be determining its own IP Address correctly
(using the wrong interface perhaps) so that the 192.1.1.111 address is not
the internal address that the NAT box is dealing with and so NAT leaves the
address unchanged because it does not recognize it.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *