opcode: Interesting PASV port range issue there... First off, I think you should be able to use the same port multiple times BUT you can only be listening (waiting for the other server to connect) once per port. Thus you could have 20 active PASV transfers without issue, but only 4 unconnected at a time as of v7.5. Previous to the v7.5 release there was a rather serious problem with re-using the ports so that limit didn't exist, BUT it also meant that it was possible to transfer the wrong file because it could give out the same port to 2 different connections. Usually this didn't make a difference since things connected pretty fast and usually connected in the order given out but it was a rather large bug I stumbled across when testing mass transfers with just 2 PASV ports...
If the remote server uses the same port to initiate all outbound traffic (like ioFTPD did before v6.4) with just 4 ports you really couldn't transfer more than 4 files in under 30 seconds because of the timeout. In that case switch the PORT/PASV roles for FXP in your client since yours is configured to use random outgoing ports. TcpView is another free Microsoft tool (or from command line: netstat) which should show you the port numbers on both sides if you're interested.
The other issue would be port numbers themselves. Obviously you had a really good reason for choosing them, but they are among the worst possible ones for the FTP. Proxy scans, worms, etc often try to connect to those ports and the FTP server would think they were for the transfer it just gave that port out to. That may mean things would fail from time to time. Most likely this would be seen as very small files failing crc checks for larger ones.
|