With IPv6 downloading plugins is impossible on one mirror



FTP: Mirrors
10 years ago
8 years ago


(Reporter: Leen Besselink, Assigned: justdave)






10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008072820 Firefox/3.0.1
Build Identifier: production

I'm using a Hurricane Electric tunnel (http://tunnelbroker.net) for IPv6 and when I click on a button for downloading an addons/extension I get: download error

Downloads get redirected to: releases.mozilla.org [ 2001:4f8:0:2::1f ] which is an 'empty' lighttpd-site with only a homepage saying: It works!

It might be a geo-dns-website-mirror-loadbalancing-problem, I don't know.

I just know at that IPv6-address there is no working: releases.mozilla.org

Reproducible: Always

Steps to Reproduce:
1. get yourself a HE-tunnel
2. use IPv4-dns from a Dutch-ISP ( http://home.nl/ )
3. If you get this response:
dig releases.mozilla.org aaaa

; <<>> DiG 9.4.2-P1 <<>> releases.mozilla.org aaaa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;releases.mozilla.org.          IN      AAAA

releases.mozilla.org.   60      IN      CNAME   releases.geo.mozilla.com.
releases.geo.mozilla.com. 60    IN      AAAA    2001:6b0:e:2018::159
releases.geo.mozilla.com. 60    IN      AAAA    2001:4f8:0:2::1f
releases.geo.mozilla.com. 60    IN      AAAA    2610:148:fd80:3d6f:209:3dff:fe12:7bf9
releases.geo.mozilla.com. 60    IN      AAAA    2001:6b0:e:2018::158

4. if firefox picks 2001:4f8:0:2::1f
5. all you get is an 404-error

So the yeast of it is:

there is no releases.mozilla.org at 2001:4f8:0:2::1f

By the way: 2610:148:fd80:3d6f:209:3dff:fe12:7bf9 (Apache/RedHat) is very slow, it seems overworked.


10 years ago
Assignee: nobody → server-ops
Severity: major → normal
Component: Administration → Server Operations
OS: Linux → All
Product: addons.mozilla.org → mozilla.org
QA Contact: administration → mrz
Hardware: PC → All
Version: unspecified → other
2001:4f8:0:2::1f is ISC.  I've notified the admin and pulled it from DNS until he tells me it's fixed. :)

2610:148:fd80:3d6f:209:3dff:fe12:7bf9 is gatech, pulled them, too.
Assignee: server-ops → justdave
Component: Server Operations → FTP: Mirrors
QA Contact: mrz → justdave
gatech is back in the pool, had their weight dropped down quite a bit in bouncer to compensate, seems to be keeping up now.  That just leaves ISC, finally made contact with the admin today (he hadn't seen my first attempt to tell him about it), so we'll see what comes of the ISC server.
Is this still an issue at all?  I haven't heard back from the admin if he fixed it or not.
I'm going to assume this has been resolved, lacking any way to test it and any response from anyone to the contrary.  If this is still an issue feel free to reopen the bug.
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 5

10 years ago
I've found releases.geo.mozilla.com and thus releases.mozilla.org does not have any AAAA-records at this time. So the whole discussion is moot.
hmm, I just added two of them back in, try again now?

Comment 7

10 years ago
I didn't really need them in DNS for testing, I'm sorry I most have misunderstood what was going on.

Alhough I cleared the cache on my recursive DNS-server, I didn't get those records you talked about.

I've tried them both via /etc/hosts
2001:4f8:0:2::1f (ISC) is still just a 'empty' lighttpd-site
and the otherone works, but it was just slow when I reported it, seems fine right now.

On the DNS-side of it, this was all I got:
$ dig +short +norecur @ns2.mozilla.org. releases.mozilla.com. aaaa
$ dig +short +norecur @ns3.mozilla.org. releases.mozilla.com. aaaa

Which again does not have an aaaa-record, I guess that's all geo-stuff.

I guess these are the ones you added:

$ dig +short @ns0.geo.mozilla.com. releases.geo.mozilla.com. aaaa

$ dig +short @ns1.geo.mozilla.com. releases.geo.mozilla.com. aaaa

But they don't seem to be involved right now.
Yeah, releases.mozilla.org is what you were looking for, not .com.  It's a cname to releases.geo.mozilla.com though (which releases.mozilla.com isn't - I know, confusing).  If you had releases.mozilla.com in the Host header when testing that might have been the cause of the empty site...

Comment 9

10 years ago
Ahh, that's where things went kinda wrong. But I did use releases.mozilla.org in my Host header. And still got the empty site, just like on 2008-09-08.
ok, mailed the admin again.
Resolution: FIXED → ---
Duplicate of this bug: 467132
I've pulled ISC out of the pool again, it's obvious he's not in a hurry to fix this.

Comment 13

10 years ago
Any chance to put IPv6 of ftp.heanet.ie into the pool? It's 3x lower latency for me compared to Gatech. They have a missing symlink, but that should be trivial to do on their side.
ISC admin says:

> This should be fixed now. (lighttpd and apache fighting over the same
> IPv6 address)
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Comment 15

10 years ago
I've tested it with 2001:4f8:0:2::1f releases.mozilla.org in my /etc/hosts and it works now.

Comment 16

8 years ago
I just had it again today. 1 of 3 extensions where not downloadable over IPv6.

2001:6b0:e:2018::1337 seems to be the IPv6-address of releases.mozilla.org that was failing. When I disabled my IPv6-address on my machine it worked.

The extensions:
Flagfox download worked (not sure if that is downloaded from releases.moz)
Go Parent Folder worked (not sure if that is downloaded from releases.moz)
Wappalyzer did not work

Hope you have a nice day anyway.
Resolution: FIXED → ---
That one belongs to UMU...

Comment 18

8 years ago
Can I get some URLs to try to hunt down for the missing plugin?

Also, we had some backend nfs issues the last couple of days which might have delayed updates and making it a bit out of sync. As far as I know this is solved now though.

Comment 19

8 years ago
OK, I checked some more things. The extensions that worked when I click on 'find update' all check versioncheck.addons.mozilla.org so I think the NFS-sync-part is the most likely cause.

Thank you for your comments.
From comment #19, sounds like it's resolved.
Last Resolved: 10 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.