PROT command sent unconditionally in Implicit SSL mode

I'm implementing SSL support in my FTP server, or, more accurately, making use of the SSL support provided by the TCPIP stack on my system. Right now, my server works in implicit SSL mode. I can connect from SmartFTP to port 990 on my server, and the logon sequence works fine. The problem is that my server doesn't currently support any of the RFC 2228 commands, in particular PROT, which is a stumbling block when I try to perform either a directory listing or a file transfer from SmartFTP. SmartFTP unconditionally sends either PROT C or PROT P, depending on the value of the SSL Data Connection Mode setting. My server responds with a 500 to both these commands, and SmartFTP won't then action the LIST, NLST, STOR or RETR.

The odd thing is that this seems to behave differently on my co-worker's system. He's able to do file transfers successfully, and I don't see the PROT command being sent before the RETR. I'm running build 1.0.979.1, he's on build 973.

Could someone explain what's supposed to happen here, whether there's been some change between 973 and 979 (I coudn't find one in the change logs), or if there's some configurational issue I'm missing?

Thanks,

Peter Hornby
Mission Viejo/CA

Hello ..

Builds below 1.0.980 are not supported anymore unless you have bought a license before.

The problem is with your server.

Regards,

Thanks, Mat,

I guess I wasn't trying to locate a problem. I was tryiong to understand whether the behavior I saw in SmartFTP was the intended behavior, and whether there's any way to perform data connection operations (file transfer or directory listings) if the server doesn't like the PROT command.

Peter