On Mon, Mar 12, 2001 at 03:39:34PM -0500, Holp, John Mr. wrote: > Some refinement; port 20 is ftp data > port 21 is ftp > port 23 is telnet
And even more refinement.... FTP supports two basic modes, 'passive' and 'active'. It's also UGLY as hell. In both modes: client connects to server port 21, this is the 'control connection' on download, In Active mode: client sends the icky 'PORT' command, which is like: PORT h1,h2,h3,h4,p1,p2 where 'h1-4' are the ip number of the host to send to (h1 being 'high') and 'p1-2' are the port number to send to (with p1 being 'high'). server connects from server port 20 to the above cited port for the 'data connection'. In other words, a REAL pain in the ass to firewall or NAT clients, because a packet filter has to snoop the whole packet and figure out the port stuff, and in the case of NAT, rewrite it. ICKY. In Passive mode: client sends 'PASV' command to the server server responds with: 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2) (same sort of sequence as above, but this time it's referring to a port on the -server- not the client). client connects to the cited port for the data connection. This is a LOT more friendly to firewalls and NAT, at least as far as the client is concerned. (It's a bit ickier for securing the server, though.) In short: if you're behind a firewall or ipmasq/nat box, you'll find PASV is a LOT more likely to work, because the connection doesn't demand special treatment: it's just another client-initiated socket, no different from http or smtp or pop3 or most other 'typical' protocols. -- CueCat decoder .signature by Larry Wall: #!/usr/bin/perl -n printf "Serial: %s Type: %s Code: %s\n", map { tr/a-zA-Z0-9+-/ -_/; $_ = unpack 'u', chr(32 + length()*3/4) . $_; s/\0+$//; $_ ^= "C" x length; } /\.([^.]+)/g;