Re: very odd STOR to OR FTP issue
ahall(a)madasafish.com was having a problem with FTP:
So it seems as though we're sending a STOR command but clients
are receiving
an OR command - which they don't understand. Is STOR becoming
truncated somehow?
I mentioned that I was seeing similar things -- the first two letters of
FTP commands being dropped.
Since then, I've checked Google Groups again, but looking for this
pattern in particular. I've found a few other people with the same
problems -- those two letters being dropped. I'm hypothesising that some
connection monitoring firewall or NAT device has problems with active
mode FTP in particular.
N.B. This all used to work fine until I rebooted our firewall the
other day. As far as I am aware, this is the only change to our
system, and we're almost positive the problem lies there. We're
thinking that something - a module maybe - either isn't running, or
isn't running correctly, or is configured incorrectly.
FTP does some odd things with ports by modern standards -- it was
designed before firewalls and network address translation (NAT). The FTP
commands get sent along a different connection to the data.
The older standard "active" FTP has connections being made in both
directions, which understandably needs a certain amount of custom coding
on firewalls or NAT devices.
Newer, "passive" FTP is similar, but involves the client making both
connections to the server. This is somewhat simpler, and doesn't need
special support on a NAT device. You can get away with much simpler
firewall support, too.
(See http://slacksite.com/other/ftp.html for more details).
I believe that most Web browsers do passive FTP by default, so that gets
tested more.
It looks to me that what's happening is that there's a bug in the active
FTP support code of certain firewalls. After data is sent back along the
data channel, the client sends a command along the command channel, but
the firewall *occasionally* eats the first two characters of the
command. Quite how that doesn't get noticed by TCP checksums, I don't
know -- maybe the buggy device is rewriting the command channel anyway
(say to handle NAT), and correctly calculating checksums on incorrect
data.
There's two bits of good news here, though. One is that "normal" TCP/IP
transfers shouldn't be affected -- it only seems to affect FTP commands.
The data should be fine.
The other one is that I've switched to passive FTP in the scripts that
were causing me problems. And I haven't seen any more problems (although
it's a bit early to tell). You can use the "passive" FTP command (in the
same way as you use "binary") to negotiate passive mode.
Hope this helps,
James.
--
E-mail address: james | Ah yes. Thingie and thingamagig, and I'll throw in
@westexe.demon.co.uk | whatchamacallit too. Because in tech support, "button"
| is sometimes a bit too technical for the average
| caller. -- "mr_scoot"