sscott@camdev.UUCP (Steve Scott) (07/19/90)
Hello, HP-UX fans!
The following is an excerpted note from one of my Big Blue Buddies with
all company proprietary info deleted ;-)
I am not sure whether or not this is an HP or an IBM problem (although
my friend does not mention this sort of a failure on other vendor's
hardware/software).
Maybe someone from within the HP labs can help here???
--------------- Excerpted mail begins --------------------------
Subject: FTP PORT command failure from HP nodes
Steve, we have seen a problem for a long time where FTP sessions from IBM
TCPIP to an HP node would fail when the FTP application issued a PORT command.
By testing the PORT command manually, I find that HP nodes are not accepting
port arguments where the first decimal portion of the port address is 3 or
less (ie PORT 192,25,80,1,3,200). I found nothing in the RFC indicating a
limit or restriction.
Is there some HP documentation about FTP PORT command limits or someone we can
call to resolve this? (A remote site) has this problem too.
History:
FTWENG is an IBM 43xx machine at IP address 192.25.80.1 via an
8232 Ethernet interface box
CAMDEV is an HP370 at IP address 192.25.80.50 running HP-UX 7.0
To see the problem, FTP from FTWENG to an HP node (CAMDEV) and issue
QUOTE PORT 192,25,80,1,3,200
(this will fail)
QUOTE PORT 192,25,80,1,4,200
(this will work)
------------------ Excerpted mail ends -------------------------------
Any ideas out there?
--
Steve Scott UUCP: {texbell|texsun}!csccat!camdev!sscott
Motorola, Inc. Internet : sscott@mot.com Telephone : 1-817-232-6317walasek@hpcc01.HP.COM (Arthur Walasek) (07/27/90)
>/ hpcc01:comp.protocols.tcp-ip / sscott@camdev.UUCP (Steve Scott) / 8:10 am Jul 19, 1990 / > > >Steve, we have seen a problem for a long time where FTP sessions from IBM >TCPIP to an HP node would fail when the FTP application issued a PORT command. > >Any ideas out there? Well Steve, Here is what we have found out. IBM starts using port address for normal communications starting at port 1000 and working its way up. HP reserves up to port 1024 or system utilities and makes available ports after 1024. Therefore, when you first bring up the IBM and try to start ftp sessions, you have to error on the first 24 protected ports before any data will actually go across. I believe that the standard is to start at 1024, and therefore it is possibly an IBM problem.... We have this problem too, and we set up the IBM to 25 transfers that will error, when TCP/IP comes up.... (really poor fix). If you need anymore information, or if I was too unclear, please mail me.... Arthur Walasek Hewlett Packard ------------------------------ Ideas expressed are my own and are no way the expressions of Hewlett Packard.
root@POPSRV.MAIL.CORNELL.EDU (The Super-user) (07/28/90)
q
barns@GATEWAY.MITRE.ORG (08/01/90)
I'm concerned that the replies I've seem posted didn't talk about the difference between local ports and remote ports. Any system can have whatever notion of reserved local ports that it cares to adopt. It should not be necessary, and in my opinion it is wrong, for one system (call it A) to know or care about the reserved ports, if any, of some other system (call it B). It isn't very convenient for me to test it, but I think that a vanilla BSD UNIX behaves as I describe, i.e., will let any of its users connect to port 1000 of a remote host, but won't let a user use local port 1000 without having the requisite privilege. When system A sends an FTP PORT command to the server on system B, the port number mentioned is a port number on system A. System B ought to believe whatever system A asserts about port numbers on system A, even if that port number is used differently on system B or elsewhere. It's the responsibility of system A to pick a reasonable port number (for example, system A shouldn't choose the port number used by a server that system A supports). But if system A thinks that 1000 is a reasonable port number, system B should be willing to talk to system A's port 1000. Note that FTP PASV also handles the ports this way. When system A sends a PASV command to system B, system B responds with a port number on system B, chosen by system B according to whatever local rules apply there. System A doesn't need to know why system B made whatever choice it made. System A should just connect to the port on system B that system B chose. Bill Barns / MITRE-Washington / barns@gateway.mitre.org