Thanks everybody for all of the traffic. It's still going if you want to take another whack at it. The current stats are: lftp 192.168.2.134:/incoming> site stats 211-Stats: Started: Sun Feb 17 11:56:14 2013, DOS version: 3.30 Sessions: 603 Active: 1 Timeouts: 107 LIST: 584 NLST: 21 RETR: 2093 STOR: 19 STOU: 0 APPE: 0 Tcp Sockets used: 2 free: 18 Tcp: Sent 188543 Rcvd 127550 Retrans 2393 Seq/Ack errs 613 Dropped 5 Packets: Sent: 191880 Rcvd: 132702 Dropped: 9 LowFreeBufCount: 0 211 OK On the "Sessions" line a timeout is a client that was connected and then went idle or disappeared for 3 minutes. The client could have been connected but after going idle for that long they get dropped. LIST and NLST are directory listings, which are really a data transfer. Combine those with the RETRs (file retrieves) and you have close to 2700 data connections being opened. Maybe not all successful, but I'll have to wait to review the logs to find out. On the TCP line the retransmit rate looks to be 1.3%. That is higher than what it has been in the past but the new code is a lot more aggressive about detecting timeouts and retransmitting early. (The previous code used a fixed 4 or 5 second timeout, which was a slow and agonizing problem on a local network or broadband connections.) You can tell by the dropped TCP packets and the dropped packets at the packet driver level that I overran the machine with incoming data. Something I was using to upload new files probably was not respecting the TCP window size; I need to hunt that down and figure out what did it. There have been some reports of dropped connections or connections refused. The machine is setup for 9 simultaneous control connections and 20 sockets total. That allows for most people to have a control connection and a data connection at the same time, but on occasion it's possible to run it out of resource and wind up with the dreaded "425 - Please try again later" message. With one data connection active the best bandwidth that can be expected is around 50KB/sec, so with multiple connections the bandwidth per connection drops pretty quickly. Luckily most people are not all pressing the "get" button at the same time. Chuck - I don't use ncftp, but that looks like the symptoms of a broken socket connection to me. I have no idea why your client feels the need to invoke tar though. There is nothing in the incoming directory that should set it off. Mike

Oh, I'm aware of it. But I use wget or lftp when I want to be recursive, Filezilla for testing with a typical GUI client, MS Win XP command line for testing with a primitive client, at least three different browsers (IE, FireFox, and Chrome), two different file manager/browsers on Android, and the straight FTP command line clients on any Linux box I have laying around in the house at the moment. You get the idea - there are almost as many clients as people. I even got a report over at VC forums that somebody used curl to mirror it. Somebody else we both know tried using straight Telnet and sending raw commands, but probably had problems getting the data transfers setup. If it is easy I would like a log - this email address is fine for it. I can also recreate it here if I need to dig further. But I still can't imagine how this is anything but a client problem at this point. Maybe something I'm doing is confusing it, but that's a badly behaved client if it just starts automatically invoking tar for you. Mike