Closed Bug 145776 Opened 23 years ago Closed 23 years ago

Install complains about network problems when using FTP as download

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: tomas, Assigned: dprice)

References

Details

(Whiteboard: [adt2 RTM])

Attachments

(2 files)

packet dump of failed install
2.62 KB, application/octet-stream
Details
Patch v1.0.
929 bytes, patch
dprice
: review+
dveditz
: superreview+
jesup
: approval+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+) Gecko/20020518 BuildID: 2002051808 The installer complains with "Setup has encountered a network problem and has paused the download. If you have just lost your network connection, please click Resume once your network has been reestablished". I'm on a DSL line and I don't have any network problems. Reproducible: Always Steps to Reproduce: 1. Download mozilla-win32-installer from nightly 2. Run it 3. It complains This started a week ago or so. Downloading the nightly has never been a problem for me.
Yes, this is a problem when using the trunk stub installer on win2k for me when trying to get the build from ftp.mozilla.org from my cube in B21 Mt. View. But, I tried running a stub installer from the 10th, which I had previously used successfully before, it no longer worked (reported network error). This would suggest that the problem may not actually be in the client stub installer, per se. (Also, the 2002-05-20-08-1.0.0 stub installer fails on the same network error). Note 1: it is trying to fetch from ftp://ftp.mozilla.org/... according to the UI in the installer. Note 2: this same installer will work if I switch to using HTTP as the transport (i.e., go into proxy settings and pick "Use HTTP for downloading", but don't set any proxy info in the text fields). Note 3: the comm. trunk stub installer pulling from sweetlou works fine.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Workaround is either to download the .sea blob installer, or to switch to using HTTP as transport.
FYI, there's no windows-xpi directory any more for latest,latest-1.0.0,latest- trunk. This disappeared around the same time that the windows net installer quit working for me as well.
*** Bug 146032 has been marked as a duplicate of this bug. ***
*** Bug 146355 has been marked as a duplicate of this bug. ***
*** Bug 146228 has been marked as a duplicate of this bug. ***
This is no good! I cant install at all using FTP as download. HTTP works fine. Something weird is going on here! Looking at the "getarchives.idi" i cant see anything wrong. It's just plain weird. Is the FTP support in the installer broken?
Severity: major → blocker
Summary: Install complains about network problems → Install complains about network problems when using FTP as download
is this just the trunk or the branch too? try installing a build from ftp://komodo.mozilla.org/pub/mozilla/nightly/...
This is trunk _and_ branch stub installers. e.g., both 2002-05-20-08-trunk and 2002-05-20-08-1.0.0 mozilla-win32-installer.exe stub installers will refuse to connect via FTP (for me, from my cube in B21). Which would lead me to think that this is a server side issue.
Note, mozilla-win32-1.0rc2-stub-installer.exe fails with this error.
Keywords: mozilla1.0
is 2002051808 the earliest instance of when this went bad?
blizzard reports seeing download errors on local ftp servers, so it sounds like its not specific to the ftp.mozilla.org farm.
I know that the problem goes back as far as the 20020517 build.
Normally i don't worry about ftp failures. Especially by people on the netscape intranet. Firewalls regularly make ftp impossible which is why the download page contains the slightly odd looking 'http://ftp.mozilla.org' links. I forget the details but the firewall is configured so that people are requred to use passive ftp and that only a certain number of people can do passive ftp at a time. At netscape, its not unusual for us to read that limit and break things like tinderbox ftp tests. Its not unusual for On the other hand, the installer is broken for me at home too and i've never experienced firewall related issues at home. and i'm able to download with ncftp just fine. I get two different error messages. One blinks away too quickly to read. "some files failed to ....." "installation has failed due to multiple crc failures" These errors show up just as the installer begins trying to download stuff. strace doesn't show anything happening.
after running "/sbin/ifconfig eth0 mtu 576" the stub installer is still broken but now it works in slow motion and i can see that mozilla was tyring to download regus.xpi and that the first dialog says "Some files failed to download correctly. Retrying". [07:47:04] <Blu3> dawn, try changing eth0 to an mtu of 576 and try again [07:47:34] <dawn> Blu3: what does that do? [07:48:29] <Blu3> dawn, if a firewall/router between you and your destination is dropping frag needed icmp, then connections will stall once packets go over the unknown MTU in the middle [07:49:46] <dawn> Blu3: and how do i restore my net connection after i'm done testing this? [07:50:35] <Blu3> dawn, ifconfig eth0 mtu 1500 [07:50:40] <Blu3> 1500 is the norm
ok, i just got the same errors when attempting to install 0.9.9 and rc1. So i guess the network must be at fault after all. I'll mail our ftp admin and see if he can figure out what's up.
FYI: normal ftp operation (from a FTP program) to ftp.mozilla.org from my end (Denmark) is no problem. It's only when using the installer to downloading using FTP. Could something in the installer be broken?
Hi. If any installer guys are here, could you answer the following question for me: How does the installer handle failure? Does it attempt to connect again or just give up if it cannot connect? Also: Any snoops that capture a broken installation would be helpfull. Thanks, --Bill Benetti
You've heard a lot of me toos already, but I'm going to add a bit of info. I've been seeing this with the installer from the Trunk for the last few days (maybe even a week). However, if I hit RESUME once or twice, it normally starts downloading with no subsequent problems. I've got HTTP 1.1 on, but pipelining off. I'm on Win98SE going to ftp.mozilla.org via a Cable Modem.
adding some installer folks
I just tried using the nightly 1.0 branch build on WinXP and it gave me the error.
*** Bug 146528 has been marked as a duplicate of this bug. ***
I'm seeing this on latest 1.0 branch build, linux, too - almost immediately the message "Some files failed to download correctly, retrying", then "Installation has failed due to multiple CRC failures"
That's interesting: A packet sniffer showed that the only command that Mozilla sent to the server was QUIT, before even the full greeting was received: [...] 220-We do not guarantee that any source code or executable code 220-available from the mozilla.org domain is Year 2000 compliant. 220- 220-Contact webmaster@mozilla.org with any problems. QUIT 220 ftp34.newaol.com FTP server (SunOS 5.8) ready.
I just tried RC3, on a different machine, with the Installer on Win98SE over a 384KB/s line, and it worked with no problems. The main differance between the two machines I use is connection speed, and firewall. On the machine where I see the problem regularly (including last night) I have a faster connection and use the free version of ZoneAlarm firewall. Zonealarm asks me if I want the Installer to access the internet, which adds a delay between the download start request, and when Zonealarm allows it to start. The other machine has a slower connection, but has no software firewall. Although there is a hardware firewall somewhere between me and the Internet.
Interestingly, RC3 network install on linux worked fine for me too.
Is this related to just mozilla.org servers, any server outside Netscape firewall, or is this something in the product code? jrgm's comment indicates that sweetlou (internal server) is ok, but I wanted to confirm.
we think there's something wrong with the networking library used by the installer code (which is special code used only by the installer) but we haven't verified it yet. It seems to have been triggered by the addition of the welcome message. (which contains the export notices which we need to display). It doesn't seem to be affecting the pr1 downloads, but those servers don't have a welcome message. Also, it doesn't look like it would affect sweetlou since there doesn't seem to be a welcome message there either. Also, its probably a different ftp daemon.
I tried chasing this for a while some time ago. I didn't manage to nail it down, but here is some info. 1. I think that this only happens on one of the ftp.mozilla.org servers (207.200.85.38 was giving me problems, I think). 2. The Linux installer will give errors but will eventually work if you resume the download enough times. The Windows installer on Windows ME *never* works. This may be due to different DNS caching behaviour. 3. I sniffed the network while the Windows installer was failing, and I found a suspicious out-of-order packet coming from the FTP server which only contained the text "ntact webmaster@mozilla.org with any probl". This looks like a bug in the FTP server, but it shouldn't be reaching the installer at all... This bug is serious and should be looked at for 1.0, IMHO.
Since this bug is soo bad couldn't we switch from FTP to HTTP until this bug has been fixed? I've had several people at work giving up on the daily installer because of this bug...:(
This is a packet dump created by tcpdump of the failed install on a WinME machine.
Forgot to say: the dump above is of the RC3 installer. Henrik: I think HTTP is the default in RC3 anyway...
David King: are you sure that you were using FTP? I think the default changed to HTTP some time before RC3, so if you didn't explicitly set FTP you probably used HTTP.
FTP is the default. In the RC3 installer HTTP is the default.
Lorenzo, I downloaded the installer using ftp from fto.mozilla.org. I must admit, however, that I don't know if the installer was using ftp or http. All I know for sure is that it was connecting to ftp.mozilla.org. If the branch uses http, and the trunk uses ftp, that would explain (possibly) the different behaviour I'm seeing. I will try getting a copy of TCPDUMP and do some sniffing today.
Hmmm, after Henrik's comment, I would say, IMHO that this problem is TRUNK only.
both branch and trunk are using FTP. The RC3 installer was changes seperately.
Oh I see, then I'll need to refine my comment in #35. If the RC3 installer uses HTTP, and other installers (Trunk and Branch) use FTP then that still explains what I have been seeing. Note that I said in #25 that the RC3 installer works fine. So, if I understand things correctly now, as long as the 1.0 installer uses HTTP in the same way as the RC3 installer, then the 1.0 release will be fine. This bug still needs to remain open to fix the original problem which is the problems with using FTP with the installer. I'm no expert on the diffs btw HTTP and FTP for downloads, but why don't we just change all installers to use HTTP?
puuh - using latest trunk and branch builds were not working, I always got the ftp error message. Using both installer and installer-sea. Help urgently appreciated.
Attached patch Patch v1.0. — — Splinter Review
Worked with dprice to flush the entire response after opening the control connection.
The problem was in libxpnet. nsFTPConn::Open() is trying to open the control connection. It was getting a return of E_READ_MORE, which indicates there is more data to be read. Rather than flushing the rest of the data, it was failing.
Comment on attachment 85369 [details] [diff] [review] Patch v1.0. r=dprice
Attachment #85369 - Flags: review+
adopting
Assignee: dveditz → dprice
Keywords: nsbeta1
I verified it with the current 1.0.0-Nightly Build: (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020529 Whem I tried to download via FTP I got the error message (I tried three times). When I switched to HTTP everything worked fine.
Comment on attachment 85369 [details] [diff] [review] Patch v1.0. I remember I did a similar fix elsewhere. Is there any other possible place that might also need a call to FlushCntlSock()? If not, then r=ssu
Comment on attachment 85369 [details] [diff] [review] Patch v1.0. sr=dveditz
Attachment #85369 - Flags: superreview+
Checked in on trunk (in case we need to test to take on branch).
Installer (via FTP) worked for me in WinME today (5/30/2002 for ..04 Win32 nightly build) for the first times in weeks. Yay! Thank you one and all.
resolving as fixed. marking adt1.0.0
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Verified
Status: RESOLVED → VERIFIED
I am not able to use ftp to download the 5/30 mozilla build- many network errors I changed to http and it is going fine
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Notwithstanding gbush's problem, for me, with the 2002-05-30-08-trunk installer stub on win2k, I did not have a problem installing.
Keywords: adt1.0.1
just installed latest trunk (2002053104) using ftp without problems.
I am successful with the 5/31 build here at work- installed on 2 machines the machine that did not work as a win95 over dialup modem
Removing adt1.0.0, and adding adt1.0.1, as we have changed milestones.
Keywords: adt1.0.0
Hey grace you wouldn't happen to be using a proxy of some kind at home? There's a separate bug dealing with proxy and ftp problems.
No, not using a proxy, pretty vanilla machine if old
Dave, I am reproducing this with the Mozilla branch build today on my WinNT machine- come by if you want to see the problem-
Keywords: mozilla1.0 → mozilla1.0.1
ok with trunk build on 95 machine
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I don't think this has landed on the branch, it's still requesting approval with the adt1.0.1 keyword.
verifying on trunk
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → gbush
Comment on attachment 85369 [details] [diff] [review] Patch v1.0. please check into the 1.0.1 branch ASAP. once landed remove the mozilla1.0.1+ keyword and add the fixed1.0.1 keyword
Attachment #85369 - Flags: approval+
Keywords: mozilla1.0.1 → mozilla1.0.1+
Target Milestone: --- → mozilla1.0.1
Blocks: 143047
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 RTM]
adt1.0.1 (on ADT's behalf) approval for checkin to the 1.0 branch. please checkin to the branch asap, then remove the add the "fixed1.0.1" keyword.
Keywords: adt1.0.1 → adt1.0.1+
FYI: Problem has returned on Win32 installer: 20020605 12:04 version.
...but working again with Win32 2002060608 13:59 version. Sorry for any spam.
Keywords: mozilla1.0.1+ → fixed1.0.1
verified on branch for 6/9 (mozilla and commercial)
Keywords: fixed1.0.1 → verified1.0.1
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: