|
I was doing this at thirty remote locations and one of the locations had this same problem.
The key responses to note in the Net::FTP Debug output are "220 Secure Gateway FTP Server" and "530 Bad Command Sequence".
The "Gateway" appears to be acting like a proxy between the client and server. It is the choice of this proxy to improperly reject what it doesn't like, instead of simply passing legitimate requests through to the server you actually intended to contact.
This "Gateway" does not agree on the order of the commands chosen by Net::FTP for a *put* command.
Specifically it does not appreciate ALLO followed by PASV; it only accepts the PASV to come first (substitute PORT for PASV if you prefer).
My hack to circumvent this 1 machine (out of 30) was to remove the ALLO comand by pretending that it already happened:
$ftp->binary;
${*$ftp}{net_ftp_allo} = 1 if( $dumb_gateway ); # AAAAAAAAHHHHHHHHHHHHHHHHHHH!!!!!!
$ftp->put( $local_file, $remote_file );
For further explanation I will refer you to the Net/FTP.pm source.
(incoming opinion:) I will consider this "Gateway" to be stupid, or at the very least, to have a bug. I find it perfectly logical to put the allocation request first, for if the server would deny such allocation, the server would not have to open and listen to a port for the incoming storage command. Resources would be saved. I will also note that while the "Gateway" responds to any further command with "530 Bad Command Sequence", rfc959, as well as dozens of googleable sites on the internet will rightfully list 530 as an Authentication failure (Not Logged In, note the x3z pattern), and 503 as a syntax error (Bad Command Sequence, x0z). So to reiterate, this "Gateway" is dumb. |
