Re: FTP broken

[Brian A May <bmay@dgs.monash.edu.au>]

On Wed, Aug 04, 1999 at 09:10:46AM +1000, Brian May wrote:
> Thanks. It is now working again:

FTP linux -> linux FTPD works.
FTP OSF/1 -> OSF/1 FTPD works (ftpd doesn't support kerberos).
FTP OSF/1 -> linux FTPD doesn't work:

[587] [silas-1:bam] ~/cvswork/heimdal/build/appl/ftp/ftp >ftp snoopy.apana.org.au
Connected to snoopy.apana.org.au.
220 snoopy FTP server (Version 6.00+heimdal-0.1h) ready.
Trying GSSAPI...
Authentication successful.

Name (snoopy.apana.org.au:bam): 
S:232-Linux snoopy 2.2.6 #2 Fri Apr 23 21:35:43 EST 1999 i486 unknown
S:232-
S:232-Copyright (C) 1993-1999 Software in the Public Interest, and others
S:232-
S:232-Most of the programs included with the Debian GNU/Linux system are
S:232-freely redistributable; the exact distribution terms for each program
S:232-are described in the individual files in /usr/doc/*/copyright
S:232-
S:232-Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
S:232-permitted by applicable law.
S:232 User bam logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
S:200 EPRT command successful.
S:425 Can't build data connection: No route to host.
ftp> dir
S:200 EPRT command successful.
S:425 Can't build data connection: No route to host.
ftp> dir
S:200 EPRT command successful.

421 Service not available, remote server has closed connection


Doing a packet trace:
13:28:56.324454 130.194.1.91.4735 > 202.12.87.129.ftp: P 1796739671:1796739781(110) ack 3835892531 win 33580 (DF) [tos 0x10]
13:28:56.324454 202.12.87.129.ftp > 130.194.1.91.4735: P 1:111(110) ack 110 win 32120 (DF) [tos 0x10]
13:28:58.334454 130.194.1.91.4735 > 202.12.87.129.ftp: P 110:188(78) ack 111 win 33580 (DF) [tos 0x10]
13:28:58.334454 202.12.87.129.3899 > 91.1.194.130.4814: S 4037960290:4037960290(0) win 32120 <mss 1460,sackOK,timestamp 370106435 0,nop,wscale 0> (DF) [tos 0x8]
13:28:58.354454 202.12.87.129.ftp > 130.194.1.91.4735: . ack 188 win 32120 (DF) [tos 0x10]
13:29:01.344454 202.12.87.129.3899 > 91.1.194.130.4814: S 4037960290:4037960290(0) win 32120 <mss 1460,sackOK,timestamp 370106736 0,nop,wscale 0> (DF) [tos 0x8]
13:29:07.344454 202.12.87.129.3899 > 91.1.194.130.4814: S 4037960290:4037960290(0) win 32120 <mss 1460,sackOK,timestamp 370107336 0,nop,wscale 0> (DF) [tos 0x8]
13:29:19.344454 202.12.87.129.3899 > 91.1.194.130.4814: S 4037960290:4037960290(0) win 32120 <mss 1460,sackOK,timestamp 370108536 0,nop,wscale 0> (DF) [tos 0x8]
13:29:43.344454 202.12.87.129.3899 > 91.1.194.130.4814: S 4037960290:4037960290(0) win 32120 <mss 1460,sackOK,timestamp 370110936 0,nop,wscale 0> (DF) [tos 0x8]
13:30:31.344454 202.12.87.129.3899 > 91.1.194.130.4814: S 4037960290:4037960290(0) win 32120 <mss 1460,sackOK,timestamp 370115736 0,nop,wscale 0> (DF) [tos 0x8]

Something currupted the IP address here - it has been reversed. It should
be "130.194.1.91" not "91.1.194.130". I have seen a similar problem
with ssh on Ultrix, but am a bit surprised to see it on OSF/1. Lets see if
debug info helps:

ftp> dir
---> EPRT |1|91.1.194.130|1106|
S:200 EPRT command successful.
---> LIST

wrong address. That rules out the server. 

Just guessing now. The problem is with the following line in ftp.c

        if (inet_ntop (data_addr->sa_family, socket_get_address (data_addr),
                       addr_str, sizeof(addr_str)) == NULL)

This is not supplied with the OS:

/* Define if you have the inet_ntop function.  */
/* #undef HAVE_INET_NTOP */

/* Define if you have the inet_pton function.  */
/* #undef HAVE_INET_PTON */


Hence, my guess is that the supplied inet_ntop_v4 is broken for little
endian systems????

-- 
Brian May <bmay@csse.monash.edu.au>

PGP signature