ZServer and ftp port-1 data channel
It appears we still have a problem with ZServer's port 20 data channel response behavior with the latest released Zope (Zope 2.2.1 (source release, python 1.5.2, linux2) and Active Mode ftp clients. In particular, when you select the port-1 behavior, medusa can't seem to bind to port 20 when port 21 command channel is specified. "ftp_server.py" line 278: if self.bind_local_minus_one: cdc.bind (('', self.server.port - 1)) After verifying that self.server.port - 1 = 20, the current behavior is that medusa simply hangs at the bind statement. If there was a permissions problem my understanding (and experience) is that one would receive: socket.error: (13, 'Permission denied') and not a process hang. Any idea why medusa simply hangs on the attempted bind? Thanks
Here's what Sam Rushing told me regarding this issue. Shane Hathaway writes:
I hear that you have found a way to get Medusa to use the correct port in active mode FTP. This could be a great benefit to the Zope community. Anything you have (diffs, modified files, or any kind of info) on the subject would be very much appreciated.
(Sam writes:) Is this the 'L-1' thing? Where the server-side port for the data channel is supposed to be '20' (I think that's right). I made some changes to the server to support it, but it's disabled by default; because 1) most people don't care 2) it has the potential to break the whole server in certain situations, depending on the OS. Other ftp servers get all acrobatic trying to Do The Right Thing, IMHO not worth it in medusa's case. See the 'bind_local_minus_one' variable of the ftp_channel class. This should be checked into the medusa cvs, but I'll attach a copy as well. --- The next email: --- Shane Hathaway writes:
wu-ftpd solves this by temporarily restoring root privileges and actually tries more than once to bind to the correct port, which is ugly.
(Sam writes:) It's even worse than that. Here's a quote from proftpd-1.2/src/inet.c: /* According to one expert, the very nature of the FTP protocol, * and it's multiple data-connections creates problems with * "rapid-fire" connections (transfering lots of files) causing * an eventual "Address already in use" error. As a result, this * nasty kludge retries ten times (once per second) if the * port being bound to is INPORT_ANY) */ (...) In other words, it's just bound to fail. A forking server can afford this sort of persistence, but in medusa I think it'd be overkill; I'd have to set up event timers, an object to maintain the retry state, etc.... [this alone it might add 50% to the size of ftp_server.py] --- I'd have to agree with Sam, it's just not worth the effort. Shane Kent Polk wrote:
It appears we still have a problem with ZServer's port 20 data channel response behavior with the latest released Zope (Zope 2.2.1 (source release, python 1.5.2, linux2) and Active Mode ftp clients.
In particular, when you select the port-1 behavior, medusa can't seem to bind to port 20 when port 21 command channel is specified.
"ftp_server.py" line 278: if self.bind_local_minus_one: cdc.bind (('', self.server.port - 1))
After verifying that self.server.port - 1 = 20, the current behavior is that medusa simply hangs at the bind statement. If there was a permissions problem my understanding (and experience) is that one would receive:
socket.error: (13, 'Permission denied')
and not a process hang. Any idea why medusa simply hangs on the attempted bind?
On 26 Sep 2000 12:50:00 -0500, Shane Hathaway wrote:
Here's what Sam Rushing told me regarding this issue.
Shane Hathaway writes:
I hear that you have found a way to get Medusa to use the correct port in active mode FTP. This could be a great benefit to the Zope community. Anything you have (diffs, modified files, or any kind of info) on the subject would be very much appreciated.
(Sam writes:) [...]
See the 'bind_local_minus_one' variable of the ftp_channel class. This should be checked into the medusa cvs, but I'll attach a copy as well.
/* According to one expert, the very nature of the FTP protocol, * and it's multiple data-connections creates problems with * "rapid-fire" connections (transfering lots of files) causing * an eventual "Address already in use" error. As a result, this * nasty kludge retries ten times (once per second) if the * port being bound to is INPORT_ANY) */
This does not occur just during 'rapid-fire connections'. AFAI can tell, it *always* fails to bind to port 20 in this case. So I don't think this is the problem. Back to my question - Why would a port 20 bind() lock up the medusa process when absolutely no other transaction is transpiring on the server? Under what condidtions woudla bind() simply stop? - not fail, just fail to return from the bind() call?
In other words, it's just bound to fail. A forking server can afford this sort of persistence, but in medusa I think it'd be overkill; I'd have to set up event timers, an object to maintain the retry state, etc.... [this alone it might add 50% to the size of ftp_server.py] ---
I'd have to agree with Sam, it's just not worth the effort.
So you are saying ZServer just isn't ever going to support Active ftp clients in the correct port-1 manner? If so, you might want to put a LARGE BANNER disclaimer about this matter as this makes ZServer unusable from most ftp clients that try to access it from behind standard a firewall. (And yes, on checking, it appears that the only OSes we could locate that come with a passive ftp client by default are the BSD's).
Kent Polk wrote:
So you are saying ZServer just isn't ever going to support Active ftp clients in the correct port-1 manner? If so, you might want to put a LARGE BANNER disclaimer about this matter as this makes ZServer unusable from most ftp clients that try to access it from behind standard a firewall. (And yes, on checking, it appears that the only OSes we could locate that come with a passive ftp client by default are the BSD's).
I didn't say it, Sam did. :-) But I agree with him. Active mode is becoming deprecated and it would take extraordinary effort for Medusa to support it 100%. The most used FTP clients these days are browsers such as Netscape and IE. They always run in passive mode; in fact you can't turn off passive mode. "wget" runs in passive mode if you use the --passive-ftp option. Almost every FTP client you find on freshmeat or download.com supports passive FTP, including WS_FTP and FTP Explorer. At least in Mandrake 7.x, even the standard ftp command supports passive mode. After logging in, enter "passive". Shane
participants (2)
-
kent@tiamat.goathill.org -
Shane Hathaway