Not new, guessing at least two months old. 2002110308 OS/2 trunk. 20020826 1.1 Mandrake 9.0 release. 2002101612 1.2b win. I looked at bug 139184, but I don't think that is the same, and I didn't find any closer match on reading any search summaries. To reproduce: 1-Open indicated URL 2-Click a directory/folder link Actual results: 1-the selected link opens right up; OR 1-a modal pops up "The operation timed out when attempting to contact service.boulder.ibm.com.", (all versions) followed several minutes later by another modal: "421 timeout (600 seconds): closing control connection." (OS/2 & win only - maybe I didn't give Linux enough time before shutdown to try win) Expected results: 1-the selected link opens right up Note: sometimes this link opens up right away, and the first selected link will open too. Less often, a second or more links can be opened. Sometimes, no link can be opened. Once the first failure occurs, an extended wait (10+ minutes?) or shutdown & restart is required before successfully proceeding. When I tested this on Linux, only the first attempt failed, and 8-10 attempts succeeded before the next failure. Same links using Netscape 3 and IE6 open right up without fail.

*** This bug has been marked as a duplicate of 177053 ***

I see the bug on fresh install of OS/2 build 2002110312 The procedure: 1. Connect to the ftp 2. If everything is fine then click Reload button 3. Repeat step 2 Usually it takes no more than two clicking on Reload button to see the bug.

yeah, I see this problem too.

this isn't a client bug as far as I am concerned. We issue a CWD and we do not recv any data on the control. Eventually, the data pipe times out. I guess we could shorten the timeout time of the data pipe to detect this error.

Someone want to attach a packet trace/ftp debug log? IS this the PASV thing again, or is this happening before we get that far?

like i said above, we send a pasv and get a response. we open a connection, then issue CWD. At this point, we hang waiting for a response.

Well, this WFM on a trunk build from last week via TestProtocols. It also WFM in blizzard's 2002103110 moz rpms. Is this something recent, then (last few days?)

Four year old Netscape and latest from M$ have no such problem. Are they getting through because of security holes, or is Mozilla doing (not) something the others are? Are they using active? Neither exhibit any apparent delay that would indicate a failed passive followed by a successful active. As I wrote in the bug originally, this behavior is old. As a longstanding habit, I usually don't even bother trying that site in Mozilla. Netscape 3 has no problem, and since it is always open for email anyway, I use it for all the things Mozilla can't handle.

I've just realised that the reason it may WFM is that my ISP occasionally experiments with a transparent FTP proxy, in which case I have no hope of ever being able to diagnose this mozilla doesn't support active FTP

Well, this is really stupid - changing the HTTP prefs from version 1.1 to version 1.0 allows it to work immediately. Why does the FTP protocol care which version of HTTP is being used???

HTTP would only be involved if you were in proxy mode. if you are not in proxy mode, the presence of any type of transparent proxy should not make a difference.

OK, so this works for me within IBM. What do I need to do to recreate it so I can create a trace? Get out from behind a firewall?

Michael, there is no need in firewall. Just follow the procedure in comment #2

mike, i think that this bug is blocked by 210125. My guess is that our data connection is denied (the server is full or something) and we do not see the cancel message propogate up.

*** Bug 220221 has been marked as a duplicate of this bug. ***

Linux build 2003101305 There is no timeouts anymore. Now Mozilla reports 425 Can't open data connection And it appears rarely than timeouts before. Things become better.

-> me

What actually happens now in current trunk is http://members.ij.net/mrmazda/tmp/Images/ftpalert.gif which on dismiss leaves the URL loaded but with no contents except for updir <ftp://service.boulder.ibm.com/ps/products/>

This seems to be working now.

What changed, the browser or the server?

No idea.

v/wfm. Camino 1.6.1 Mac OS X 10.5.x.