On 6 Jul 2004 12:00:53 -0700
firstname.lastname@example.org (FreeDiver) wrote:
> Our Sun E3500 server has been upgraded from Solaris 2.6 (105181-17 )
> to Solaris 9 (112233-11). There are no changes in any of the FTP
> binaries. We take & use all the default FTP binaries and values which
> come with Solaris 9.
> Our 3rd party FTP program, which extract and put datas to our E3500
> server used to work when it's under Solaris 2.6. However, since the
> OS upgraded to Solaris 9, we have been getting the following error
> messages and the program fails. There's no change in the 3rd party
> FTP program end.
Have you tried simulating the behaviour of that program
with another FTP client? If this works, the problem is
with the FTP client, not with the server. Why you start
off by blaming the server escapes me - there's far more
chance that your 3rd party FTP client has a problem. It's
in all likelihood very poorly tested compared to the FTP
daemon on Solaris 9. If you decide to use the FTP client
from Solaris 9, issue the command "debug" first, so that
you can follow the protocol:
| ftp> debug
| Debugging on (debug=1).
| ftp> dir crash*
| ---> PORT 192,168,1,21,141,117
| 200 PORT command successful.
| ---> TYPE A
| 200 Type set to A.
| ---> LIST crash*
| 150 Opening ASCII mode data connection for /bin/ls.
| -rw-r--r-- 1 sae staff 2047 Feb 19 11:47 crash.1
| -rw-r--r-- 1 sae staff 2047 Feb 19 11:48 crash.2
| -rw-r--r-- 1 sae staff 2047 Feb 19 22:35 crash.3
| 226 Transfer complete.
| remote: crash*
| 189 bytes received in 0.015 seconds (11.94 Kbytes/s)
| ---> TYPE I
| 200 Type set to I.
| ---> NLST crash*
| 150 Opening ASCII mode data connection for file list.
| 226 Transfer complete.
| remote: crash*
| 27 bytes received in 0.011 seconds (2.35 Kbytes/s)
> We need help in resolving the problem. Specifically,
> - Are there any latest FTP related patches for Solaris 9 ??
There are no bugs as you describe in the Solaris 9 FTP daemon.
> - We noticed the FTP solaris 9 uses different set of "ports" as
> compared with that in solaris 2.6. Is it contributing to the problems
Huh? The ports that matter (20 and 21) are fixed by the protocol.
Port mode will use any available, non-privileged port for the
data channel, and it really doesn't matter unless your network
imposes some kind of restrictions on specific port ranges.
> - In solaris 9 server , we see "in.ftpd -a" processes whereas in
> solaris 2.6 server , we see "in.ftpd". Is there any difference ??
Read the man page. It enables the use of the ftpaccess.4 file.
> - In solaris 2.6 server , we see "226 ASCII Transfer complete"
> message at the end of remote client ftp session window when he/she
> performs a simple "ls" commands during the ftp session. However, in
> solaris 9 server, we see "226 Transfer complete" message at the end of
> remote client ftp session window
> when he/she performs a simple "ls" commands during the ftp session.
> Please note that, we didn't go with binary mode this time.
> Why is there a difference between the 2 Transfer complete messages
Because they're different programs?
The only thing that matters to the protocol is the number
(226) and that's identical.
> Any FTP config files in Solaris 9 which control and determine
> what completion messages are available ??
Yup, and a "man ftpd" would have told you which ones. Have
a look in /etc/ftpd.
> 2004/06/29 14:11:24 STATUS [main] Creating new FTP connection to
> server:[172.20.6.20] on port 21
> 2004/06/29 14:11:24 STATUS [main] Connected to server:[172.20.6.20]
> on port 21
> 2004/06/29 14:11:24 STATUS [main] Logged in to server:[172.20.6.20]
> as user:[e1ftpa1]
> 2004/06/29 14:14:24 EXCEPTION [main]
> com.banctec.bca.ftp.FtpException: After sending command:[NLST]
> couldn't read:[response code:226 (Closing data connection, requested
> file action successful) OR response code:250 (Requested file action
> okay, completed.)] from:[e1ucor01.rich.frb.org/172.20.6.20:21] -
> java.io.InterruptedIOException: Read timed out
The data connection didn't work for one or other reason.
Most likely, you're seeing the effects of a router that
blocks the ports negotiated by the client and server, but
you'll need an FTP client that shows the requests and
responses (in the style of a more traditional FTP client,
which is why I suggest simulating the transfer with an
"What is stated clearly conceives easily." -- Inspired sales droid