68199 - ftp connections to localhost hang after login banner

Status: VERIFIED WORKSFORME

(Core Graveyard :: Networking: FTP, defect)

Description

[Bradley Baetz]

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.

Comment 1

[Bradley Baetz]

Attachment: tcpdump of local ftp session (the duplicate packets are because its local - ignore them)

Comment 2

[Bradley Baetz]

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.

Comment 3

[Bradley Baetz]

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.

Comment 4

[tenthumbs]

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.

Comment 5

[Bradley Baetz]

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.

Comment 6

[Bradley Baetz]

Attachment: nsSocketTransport:5,nsFTPProtocol:5 log file from startup (google is my start page)

Comment 7

[Bradley Baetz]

Attachment: gzipped (7M uncompressed!) log file of listing a /pub with 500 entries after deleting componants.reg

Comment 8

[Doug Turner (:dougt)]

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.  

Comment 9

[Doug Turner (:dougt)]

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

Comment 10

[Tom Everingham]

verified

Comment 11

[benc]

(placeholder for using linux-bundled ftp as testcase)