ahall@xxxxxxxxxxxxxx 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" -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
