I was trying to work out why the directory viewer was so slow (to see if its my local changes that cause it), and so I set up an anon ftp server on my machine (using the RH7 anonftp and wu-ftpd packages). This didn't work - mozilla just hangs on the connection. Its not the server - Blake managed to ftp in fine, and ns 4.x and ncftp both connect locally. With NSPR_LOG_MODULES set to nsFTPProtocol:5, I get the following log: 1024[80549a8]: nsFTPChannel::AsyncRead() called 1024[80549a8]: (80eccf0) nsFtpState created 1024[80549a8]: (80eccf0) Establishing control connection... 1024[80549a8]: (80eccf0) trying cached control 1024[80549a8]: (80eccf0) creating control 1024[80549a8]: (80d73e0) nsFtpControlConnection created 1024[80549a8]: (80eccf0) SUCCEEDED 1024[80549a8]: (80eccf0) Waiting for control data (0)... and nothing else. Tracing the connection with ethereal (I'll attach the log), shows that the ftp server prints out the login banner (220 ...), but it appears that mozilla doesn't get it. (I used netcat locally, and the nspr log doesn't show anything there either.) I can connect to other ftp servers with mozilla without problems.

Its not localhost - using 127.0.0.1, or my ppp0 ip, still has the error (although those all go over the loopback interface) I've also corrected a typo in the original bug summary.

OK, this is just strange: delete components.reg, start mozilla, and you can go to ftp://localhost/ with no problems. Close it, start again, and you have the problem I described. This is 100% repeatable. Its definately a mozilla issue - at all times ncftp and ns4.x can connect without problems.

Since the ftp server is on your own machine, you can add -d and/or -l to the command line what starts it and teh daemon will log lots of stuff to the syslogs. The only trick is finding where the daemon is started, usually from inetd. If so, edit /etc/inetd.conf and restart inetd. The system logs will probably be more useful than packet dumps.

No extra log comments. The componants.reg thing may be a red herring - although I tried it about 5 times yesterday and that got it to work, now it doesn't.

looks like the same problem as the 100% cpu peg. Basically, the write remains in the select list even when there is no data to write. This should be fixed when my channel branch lands in a few days/hours. No clue why deleting the component.reg file has an effect.

Assuming that your ftp server is supported, this should be fixed as it works for me with a few different ftpd's.

verified

(placeholder for using linux-bundled ftp as testcase)