• Please review our updated Terms and Rules here

DOS FTP Server Testing (Round 2)

Ok, Chuck is having too much fun. Testing is done for now, and I have a *GAPING* whole to fix.

Thanks for all of the help guys!
 
Transfer speeds locally are around 22KB to 25KB/sec, if there is only one other transfer going on. The TCP/IP code with this Ethernet card can do 100KB/sec without disk I/O. Disk I/O is around 50KB/second with this setup, assuming sequential reads. So the other 25KB/sec is lost to doing memory copies in the Open Watcom C runtime or in DOS.

I am pretty good about parsing the paths and enforcing that people stay 'in the sandbox' if one is assigned. (With more privilege you can move around the entire machine, including changing drive letters.) But Chuck caught me on device names like CON: and CLOCK:. CON was harmless, but CLOCK$ really nukes the machine. :)


Mike
 
mbbrutman said:
LIST corresponds to a full directory list, including file sizes and dates. NLST is the shorter 'name list' which only gives names. Apparently none of the clients or people connecting use the 'ls' command (or the equivalent) to get the abbreviated name list. Interesting, but not important.
Mike
Click to expand...

Did the ls command work on the last test? I use FTP all the time so typing ls is not even a concious action, and I'm sure I did it over and over. Anyway, the last quarter hour I've been trying a bunch of clients and finally had the sense to ping. It seems the server is down.
 
Ole Juul said:
Did the ls command work on the last test? I use FTP all the time so typing ls is not even a concious action, and I'm sure I did it over and over. Anyway, the last quarter hour I've been trying a bunch of clients and finally had the sense to ping. It seems the server is down.
Click to expand...

It's down and done for now. ChuckG found a hole big enough to drive a truck through and it's a fairly simple fix, but I want to make sure that I do it right.

The ls command should work - there isn't much to it and I've tested it. I never use it either. :)


Mike
 
mbbrutman said:
But Chuck caught me on device names like CON: and CLOCK:...
Click to expand...
Have you taken into account other reserved device names like AUX: NUL: PRN:, etc.? I'm sure there are more than that. I remember back in the day that attempting to read or write to a file of those names could cause programs to fail or lock up.

Steve
 
SteveH said:
Have you taken into account other reserved device names like AUX: NUL: PRN:, etc.? I'm sure there are more than that. I remember back in the day that attempting to read or write to a file of those names could cause programs to fail or lock up.

Steve
Click to expand...

Bah!
I was going to try to upload a file called NUL but now...
 
I had a logic flaw. The code in question was designed to check for the existence of a file, and it would do so by STATing the file in question. I would then check if the file was a regular file, and return '1' if it was. That works great. But if the code returned a zero, that doesn't mean the file didn't exist. It means that the STAT failed (doesn't exist), or it succeeded (exists) but was not a regular file. And that was the bug.

If STAT doesn't work on the reserved or device driver installed names I'll go a little further and run the device driver chain to pick up all of the names I need to watch out for.

While checking the debug log this morning I found another cute, and more sinister bug. Here is the scenario:

  • User client is connected
  • User client sends PASV command, causing server to listen for a data connection
  • User client makes data connection on a new socket
  • User client disconnects control connection, ending the session

My code should have cleaned up the data connection and recycled the socket. But there was a bug there too and it skipped cleaning up the data connection. I thought I had most of those holes fixed, so that's a good one to find (and correct).

It was connection number 70 that first exposed the bug. Connection number 180 hit it again. It's a small timing window, and it illustrates why the testing is so valuable.
 
Ok, all of the current known bugs are fixed! :)

It is open for testing again if anybody is interested. Besides the normal browsing and looking at files, feel free to try reserved device names, trying to break out of the sandbox, playing with raw PORT and PASV commands, etc.

The address is the same: ftp://96.42.228.74:2021/


Mike

PS: Vorpal Bunnies are welcome ...
 
Last edited:
I tried a couple of different clients, which was probably more educational for me than useful to the author. :)

I discovered, regarding the "ls" command, that unless I use passive mode, it does not work. It is interesting, however, that I can connect without passive and it will respond properly to "pwd".

Also, when using lftp, I could use "cat" and "less" to read files. Yes, lftp is a very capable client and no doubt manages a lot of things on it's own. However, when I used a generic FTP client "cat" and "less" were not available, but neither was "type".
Code: 
ftp> type aol.txt
aol.txt: unknown mode
 
The LS command (NLST under the covers) works the same way as the DIR command (LIST under the covers). So if LS requires passive mode, then DIR requires passive mode too. And so will any file transfer.

Now, here is an interesting twist - there is a 'STAT' command in the FTP spec. STAT without parameters gives you the server status. (Try QUOTE STAT in your client to see the output.) The STAT command with a parameter though gives you the equivalent of a DIR, except it doesn't require another data connection - it just sends the data through the control connection. Consider it a backup to the standard DIR command that you can use when PORT or PASSIVE are not working. (Although PASSIVE should just about always work.)
 
mbbrutman said:
The LS command (NLST under the covers) works the same way as the DIR command (LIST under the covers). So if LS requires passive mode, then DIR requires passive mode too. And so will any file transfer.
Click to expand...

I just thought it was interesting that "PWD" worked in active mode while "LS" and "DIR" didn't.

Now, here is an interesting twist - there is a 'STAT' command in the FTP spec. STAT without parameters gives you the server status. (Try QUOTE STAT in your client to see the output.) The STAT command with a parameter though gives you the equivalent of a DIR, except it doesn't require another data connection - it just sends the data through the control connection. Consider it a backup to the standard DIR command that you can use when PORT or PASSIVE are not working. (Although PASSIVE should just about always work.)
Click to expand...

Useful command, thanks. :) I just tried 'STAT' and 'QUOTE STAT'. Both respond in lftp, but on a generic FTP client 'STAT' by itself says "unknown command".
 
FTP opens a new socket for data connections. The commands that cause data connections are the directory list commands, gets and puts. Anything else uses the existing control connection. So you can PWD, CWD, etc. without worrying about active or passive because another data connection is not required.

If your client doesn't understand STAT or gives you local status, try 'QUOTE STAT' - that passes the command straight to the FTP server.
 
All done for now! (It's time to give the machine a rest.)
 
Just some final notes on the last round of testing ..

There were 723 logins, of which 75 timed out after 3 minutes. There were 413 total directory listings, 508 files successfully sent, and 16 uploaded. The number of TCP/IP packets sent was over 65,000, while received was only 52,000. 16 TCP/IP packets were dropped due to a lack of space - either the sending side was being overly agressive or the machine got busy and didn't process packets fast enough.

There was one user in particular in the EU who was responsible for about the last 500 of those connections. While I appreciate the enthusiasm and the testing, the Zip drive started smoking so I had to do some emergency filtering to give the machine a break. (No, it wasn't that bad - but after the first 200 connections I figured enough had been done.) (That test had to be scripted after the first few connects, and I'd like to learn how to do that.)

I didn't find anything significant in the log this morning, so I think that at least for now, it's done. Next is to put it in the mTCP package and release a new version.

Thanks all! And if you need an FTP server for DOS ... :)


Mike
 
You must log in or register to reply here.
Back
Top