Cannot get INET_FTPLogin to work with Solaris 10

[mcrossman]

I am using the INET_FTP commands (Login, Retrieve, Send, etc.) to ftp off a file from a computer running Solaris 10.  We were running Solaris 7 on the remote computer before and there was not any problems ftping off the file.  Unfortunately when I tried to ftp the file off of Solaris 10, my program justs sits there and eventually times out.  I am using LabWindows 6.0.  I do have the SMF FTP process for Solaris 10 turned on.  Does any have any ideas?

Thanks.

[AEDavid]

Hi mcrossman,

Please try using the two example programs (Networking >> Internet & Web >> simpftp.prj and ftpclnt.prj) and please let me know if they also time out.

[mcrossman]

Well David, I ran the two programs without any successful results.

When I ran the simpftp.prj file,  I got error-20 message "Not authorized to access FTP server with given user id and password".  I verified that all the information entered was correct.  I then tried to FTP through the DOS window to verify that I could still FTP from the Windows computer to the Solaris computer.  I did not have any problems using FTP there.

When I ran the ftpcInt.prj file, I go error-4 message "Operation timed out".  It looked like it almost worked.  It was able to show the correct home directory for the user, but it could not show the contents of the directory.  It took about a minute or so for it timed out trying to retrieve the contents of the directory.

I am still stumped.  Do you have anymore ideas?

Thanks for all your help.

[Ben M]

Hello mcrossman,

Does the user account have access to the files in the directory?

[mcrossman]

Yes, the user has access to that folder and its contents.

Message Edited by mcrossman on 06-22-2007 11:50 AM

[AEDavid]

Hi mcrossman,

What ftp server port is it on?  Also, please try this:

Note  If an FTP-client application is run from behind a firewall, use the passive, or client–initiated, mode of establishing an FTP data connection. After opening an FTP connection, call the low–level InetFTPSetPassiveMode function to set the data connection mode to passive mode.

What exact function calls were giving each error you mentioned above in the sample project?

[AEDavid]

Hi Mcrossman,

Here are two more things to try:

1. Ftp to ftp.ni.com/outgoing and see if you are able to connect there.
2. Downloading the evaluation version of CVI  to see if the newer version of the Inet library solves this issue. 

[menchar]

I also had trouble FTP'ing to a Sun server after installing WinXP SP2 on the client, which imposed a firewall.

The passive login call made it work on the XP SP2 client machine, but that code then no longer worked on an XP SP1 client machine

This was with CVI 7.1.1

Menchar

[mcrossman]

I found a fix for the FTP problem.  I tested it and it works.

I "snooped" the newtork packets for using the FTP command for both a Solaris 7 and Solaris 10 machine. I found the solution by reading through the man pages in Solaris.  The following parameter in the file /etc/ftpd/ftpaccess controls the end of transfer behaviour:

flush-wait
Controls the behavior at the end of a download or directory listing.  If yes, shutdown the data connection for sending and wait for the client to close its end before sending a transfer complete reply on the control connection. This is the default behavior. If no, close the data connection and send the transfer complete reply without waiting for the client. With this behavior, data loss can go undetected.

http://docs.sun.com/app/docs/doc/816-5174/6mbb98uf8?q=flush-wait&a=view

The Windows computers waits for the transfer complete message before closing the data connection as I observed with the protocol analyzer.

So, a lockout was created when Sun changed its FTP services in Solaris version 9 so that, by default, the server waits for the client to close the data connection before sending the transfer complete message on the control connection. 

The fix is simply to add this line to /etc/ftpd/ftpaccess on the Solaris computer:

flush-wait  no  real, guest, anonymous

Thanks for all the help.

[AEDavid]

Thanks for letting us know, mcrossman.  Best of luck on your app!