Closed Bug 99233 Opened 24 years ago Closed 24 years ago

FTP site doesn't load : ftp.asus.com

Categories

(Core Graveyard :: Networking: FTP, defect, P1)

Product:
Core Graveyard
Component:
Networking: FTP
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: wd, Assigned: bbaetz)

References

(
URL
)

Details

(Whiteboard: [PDT+] FIXED-ON-TRUNK FIXED-ON-BRANCH)

Attachments

(1 file)

patch
746 bytes, patch
timeless
: review+
bbaetz
: superreview+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010910 BuildID: 2001091003 The FTP site ftp://ftp.asus.com will not load with Mozilla Reproducible: Always Steps to Reproduce: 1.go to ftp://ftp.asus.com 2. 3. Actual Results: Says "Beginning FTP Transaction" and then "Finished FTP Transaction", but nothing comes up. Expected Results: FTP site contents displayed. Works w/ IE and Netscape
I also see this behavior with Windows 2000 with ftp://ftp.asus.com. I don't know if this is related, but going to a non-existant FTP server also give the same result (e.g. ftp://ftp.iplanet.com doesn't pop up the name doesn't exist like it does for Netscape 4.78). I'm on a DSL line behind a Linksys router (using NAT), but the Netscape 4.78 works fine. I'm running Mozilla .94.
Verified that it still exists in today's nightlies on Win2k (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+) Gecko/20010916).
didn't this just get fixed in bug 92582?
Well the fix for bug 92582 doesn't fix this one, so I'd have to say no. I'm using 2001091803 and ftp://ftp.asus.com doesn't display anything ( ftp://ftp.microsoft.com does work fine )
I see the transation stall after the client issues the RETR after a failed SIZE: T 216.136.179.237:21 -> 10.4.250.18:2700 [AP] 227 Entering Passive Mode (216,136,179,237,8,7)... ## T 10.4.250.18:2700 -> 216.136.179.237:21 [AP] SIZE /.. # T 216.136.179.237:21 -> 10.4.250.18:2700 [AP] 550 /: The system cannot find the file specified. .. # T 10.4.250.18:2700 -> 216.136.179.237:21 [AP] RETR #
For some reason mozilla splits the RETR commmand across two packets; in this case "RETR " and "/\r\n". When ftp.asus.com sees "RETR " it immediately issues a RST on both the control and data sockets and mozilla gives up. ftp.microsoft.com and ftp.asuscom.de wait until they get the entire command so they work. Clearly ftp.asus.com is broken but I'm sure there are more like it out there so the question becomes why does mozilla do such an odd thing with the packets. I tried this on my Linux machine and mozilla does the same thing with <ftp://localhost/>. If I try <ftp://localhost/pub/> then mozilla splits "RETR /pub\r\n" into "R" and "ERT /pub\r\n". Bizarre, and shouldn't happen.
reassigning to bbaetz@cs.mcgill.ca.
Assignee: dougt → bbaetz
So I don't know why this is being spread across multiple packets, but I'll look into it. ftp.asus.com is really broken if it doesn't accept that, though.
Status: NEW → ASSIGNED
bradley, yesterday I did a trace on this and did not see that we even sent the path after the RETR. If this is truely what is happening, it would explain the stall perfectly.
dougt: yuck.
Target Milestone: --- → mozilla0.9.6
Mozilla gives up when it gets the RST. It never sends the rest of the command. You probably also want to change the platform to All.
Bug 92582 implies that this is now linux only, evne though it was filed on windows. Can someone confirm that? The connection may be being closed by the proxy when it sees that there is no path in the one packet.
OK. The good news is that I know whats happening, and I think I know why. The bad news is that I'm not sure what to do about it. Whats happening in this and a couple of similar bugs which I'll dupe to this is that we send the string "RETR /\r\n". The space is the 64th character we send. And we use a pipe with a 64 byte segment size. So its split over two packets, and the server dies. I'm not really sure why this causes it to be split up, since I don't know how that stuff works. We could just up the segment size, but that could cause the same problem later. Or can we tell the pipe to combine segments and/or begin a new segment when all data is flushed from the pipe? Per #mozillazine, -> All/All
OS: Windows 98 → All
Hardware: PC → All
*** Bug 96727 has been marked as a duplicate of this bug. ***
...and upping the count from 64 to 6400 make this work.
Severity: normal → major
Priority: -- → P1
Target Milestone: mozilla0.9.6 → mozilla0.9.5
have you tried with a recent nightly build... dougt just checked in a RETR related patch that may help this bug as well.
darin: No, thats not it, although you need that patch as well. I can get it to work by using ftp://anonymous:mozil@ftp.asus.com/, so that the 64 byte boundary matches up with the end of the line. Doing that isn't reliable though.
Actually, I was wrong. That url lets me get further, but then we still hang. Changing the buffer to 1024 bytes makes it work, though, so I think that that or something similar is the correct fix for this.
*** Bug 95386 has been marked as a duplicate of this bug. ***
Blocks: 101002
OK, there are lots of dupes of this. What changed? My patch fixes it, but I'm wondering if something else broke it, since that number has been there for ages. darin, dougt? nsPipe2.cpp hasn't changed, but did something else play with it? I want to understand this a bit.
Severity: major → critical
In last nightly (2001092308) on Win32 I still have the FTP bug : Begin FTP transaction / Connecting... / Finished FTP transaction and no window refresh. ftp://anonymous:mozil@ftp.mozilla.org/ works fine ftp://ftp.mozilla.org/ doesn't work
Attached patch patch — — Splinter Review
Comment on attachment 50593 [details] [diff] [review] patch dougt says: r/sr=dougt
Attachment #50593 - Flags: superreview+
Attachment #50593 - Flags: review+
Fix checked into trunk. Can someone who was seeing this with a firewall please confirm this in tomorrow's builds?
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
this patch is really wacky... why are you making the pipe's segment size larger than the pipe's maximum size? you are definitely abusing the parameters, but why does this help?
As discussed on irc with darin, I changed the second 256->1024 as well, and checked it in.
Using buildid 2001092503 on Win32 : It works !! Thanks.
wfm now with 2001092508 linux. did not with 2001092323
*** Bug 96471 has been marked as a duplicate of this bug. ***
darin, dougt: want this for the branch? QA - this particular bug is fixed (based on reporter feedback), but please verify the dupes, and reopen any which didn't turn out to be this problem. Thanks!
Keywords: nsbranch
Whiteboard: FIXED-ON-TRUNK
tever, can you run through your ftp site list and verify this does not break anything. If it doesn't, I think it should be put on the branch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sweet.. this works for me now (I'm behind a FW-1 machine). Yay, I can FTP again! ;-) -T
Looks like this has reviews completed. If so, please mark as nsbranch+ and write a note to pdt2@netscape.com so we can get this approved for eMojo Netscape branch check in.
adding nsbranch+
Keywords: nsbranch → nsbranch+
Please check this into the branch. Marking PDT+...
Whiteboard: FIXED-ON-TRUNK → [PDT+] FIXED-ON-TRUNK
fixed-on-branch
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] FIXED-ON-TRUNK → [PDT+] FIXED-ON-TRUNK FIXED-ON-BRANCH
*** Bug 94726 has been marked as a duplicate of this bug. ***
*** Bug 100889 has been marked as a duplicate of this bug. ***
VERIFIED: Win32 Commercial 094 2001-10-04-05 and Trunk 2001-10-04-09. passed ftp functional test + sites given as examples here. I'll check the sites in the duplicates next week, but this works now. I check Mozilla 0.9.4 Linux, and it didn't work.
Status: RESOLVED → VERIFIED
*** Bug 79753 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: