246193 - IPV6: doesn't revert to IPv4 if IPv6 connect fails

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040610
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040610

I cannot open <http://ftp.heanet.ie/pub/mozdev/googlebar/XPI-stable.xpi> after
disabling IPv6 autoconfig (before doing that, it didn't work either as IPv6 was
used for this connection and IPv6 doesn't work here, but this also affected lynx).

Reproducible: Always
Steps to Reproduce:
1. From the command line, type
  mozilla http://ftp.heanet.ie/pub/mozdev/googlebar/XPI-stable.xpi
Actual Results:  
I get the following message in the terminal:

Error loading URL http://ftp.heanet.ie/pub/mozdev/googlebar/XPI-stable.xpi :
80004005 (NS_ERROR_FAILURE)

and Mozilla doesn't open anything.

Expected Results:  
Mozilla should open the URL.

The above URL can be opened with both lynx and wget (from the same machine).

My kernel is a 2.6.6 and I disabled IPv6 autoconfig by doing:

echo 0 > /proc/sys/net/ipv6/conf/eth0/autoconf

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

is this because of the XPI whitelisting stuff?

dveditz, should the whitelisting show an error message for non-whitelisted sites?

Comment 2

[Vincent Lefevre]

I don't know what you mean by the "XPI whitelisting stuff", but there is the
same problem with non-XPI URLs, like <http://ftp.heanet.ie/pub/mozdev/googlebar/>.

Comment 3

[Vincent Lefevre]

I did a

  strace -f -o strace.out mozilla http://ftp.heanet.ie/pub/mozdev/googlebar/

and saw the following:

20233 connect(33, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6,
"2001:770:18:2::1:100", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1
 EADDRNOTAVAIL (Cannot assign requested address)

2001:770:18:2::1:100 is the IPv6 address of ftp.heanet.ie.

Comment 4

[Daniel Veditz [:dveditz]]

I have no problem going to the googlebar/ link with or without IPv6 disabled.
The whitelisting issue can be ruled out by setting xpinstall.whitelist.required
to false and re-trying.

Comment 5

[Vincent Lefevre]

Setting xpinstall.whitelist.required to false and restarting Mozilla on the
above URL doesn't change anything. I still get the same error.

Comment 6

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040608

following entries in about:config are type: default string

xpinstall.blacklist.add 
xpinstall.dialog.confirm chrome://communicator/content/xpinstall/institems.xul
xpinstall.dialog.progress chrome://communicator/content/xpinstall/xpistatus.xul
xpinstall.dialog.progress.type

xpinstall.enabled default boolean true
xpinstall.whitelist.add user set string
xpinstall.whitelist.required default boolean true

As I tested this with a profile I´ve also used with current 1.8 nightlies,
I created a fresh profile via Tools->Switch Profile, same result.


I resetted xpinstall.whitelist.add and got mozilla.org, mozdev.org,
texturizer.net as value, modified this by adding heanet.ie, saved, and tried to
load the xpi in another tab. No action, reopening about:config was showing an
empty xpinstall.whitelist.add user set string.

The string is cleared only on trying to install the xpi from heanet. Didn´t try
to install xpi from other allowed or unlisted addresses.
I can change the value. close the tab, open about:config again, and the value is
still there. Doesn´t matter if I close the tab or not, if I´m loading the heanet
URL, the value is cleared.

Comment 7

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040608

restarted Mozilla, opened this bug in a tab, about:config in another, checked
the value of whitelist.add to be as I've set it in the last session:

xpinstall.whitelist.add default string mozilla.org, mozdev.org, texturizer.net

Installed LiveHTTPHeaders from mozdev.org, installation went normally, but
switching back to the tab showing about:config whitelist.add had changed:

xpinstall.whitelist.add user set string

didn´t change anything, restarted mozilla, checked LiveHTTPheaders was in the
menu, installed Leodict from mozdev.org, installation went normally, but I don´t
have mozilla restarted to check if it is available.

I´ve tried this with setting xpinstall.whitelist.required TRUE.

So it seems xpi installation is restricted to the default websites,
wether the list is shown or not, that list can be changed, websites added, but
added websites don´t load, trying to load any xpi hides the list.
Installation went normally means, I´ve been asked if i really want to install
the xpi, and if got two messages afterwards, telling me: installation was ok',
and asking me to restart the browser.

Shouldn´t this be a blocker?
Seems that XPIs can only be installed from mozilla.org, mozdev.org,
texturizer.net, so some people won´t be able to install themes, I assume.
I´ve tested only installing extensions from mozdev, successfully, and from
heanet, to no avail.

Comment 8

[Vincent Lefevre]

Note that I can't access to <http://ftp.heanet.ie/pub/mozdev/googlebar/>. So,
the bug doesn't concern only XPI installation.

Comment 9

[Jean-Marc Desperrier]

From what I see : 

- Vincent has a IPv6 related problem where Mozilla is not using the correct
network parameters. I think his case is not easy to reproduce because he has a
partially usable IPv6 connection (DNS works, not connect) that he wishes Mozilla
doesn't use at all.

- Hermann seems to have found a problem in the XPI white-list configuration.

Those are two completely seperated issues.

Herman, please open a separare bug for the white-list problem (check for
duplicates, if your bug is confirmed, I expects them to come fast), so that we
keep here here only the IPv6 on Linux kerneal 2.6.6 part, which also affects
non-XPI URLs.

Vincent, what happens when you open ftp.ipv4.heanet.ie ?

Also the bug to add sites to the white-list is 246097.
I'm afraid this said that ftp.heanet.ie is a too generic host to add it to the list.

Comment 10

[Daniel Veditz [:dveditz]]

the xpinstall.whitelist.add pref is a *command*, not the actual whitelist. The
value will hang around for a while, but when an install is kicked off it's
processed and blanked out.

The actual whitelist is the "hostperm.1" permission manager file in your profile
(also used for cookie site permissions, image blocking per site, popup
whitelisting).

Comment 11

[Vincent Lefevre]

No problem with ftp.ipv4.heanet.ie.

Mozilla has the same problem with http://ftp.mozilla.org/pub/mozilla.org/ :

Error loading URL http://ftp.mozilla.org/pub/mozilla.org/ : 80004005
(NS_ERROR_FAILURE)

My IPv6 connection is now completely unusable, since I've disabled IPv6
autoconfig: my machine no longer has an IPv6 address (except the default local
ones associated with the eth0 and lo interfaces). So, under these conditions, it
should not be a particular case, i.e. I suppose that users who have IPv6 support
in the kernel and disabled autoconfig should be in the same case as me.

Comment 12

[Vincent Lefevre]

I've done a strace on lynx too. It also tries an IPv6 connection (which fails,
like with Mozilla -- this is normal), but then reverts to IPv4. I think that
Mozilla should do the same.

Comment 13

[Lorenzo Colitti]

(In reply to comment #3)
> 20233 connect(33, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6,
> "2001:770:18:2::1:100", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1
>  EADDRNOTAVAIL (Cannot assign requested address)
> 
> 2001:770:18:2::1:100 is the IPv6 address of ftp.heanet.ie.

Hmm... if I remember what I was thinking when I wrote in bug 223145 comment 7,
we call it quits and bail out of the connection if we get a
PR_ADDRESS_NOT_AVAILABLE_ERROR (which is EADDRNOTAVAIL). 

We probably need to treat PR_ADDRESS_NOT_AVAILABLE_ERROR as a temporary failure
and retry the next address instead of giving up.

Comment 14

[Darin Fisher]

Attachment: v1 patch

This should do it.  Can someone please test this out?

Comment 15

[Lorenzo Colitti]

Comment on attachment 150825 [details] [diff] [review]
v1 patch

Looks good. r=lorenzo

Comment 16

[Darin Fisher]

fixed-on-trunk

Comment 17

[Lorenzo Colitti]

We need this on aviary as well.

This completely blocks installing extensions from update.mozilla org if IPv6 is
turned on but not configured (e.g. Fedora Core 2, recent debian distros).

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 150825 [details] [diff] [review]
v1 patch

a=asa for branches checkins.

Comment 19

[Darin Fisher]

fixed1.7.x, fixed-aviary1.0

Comment 20

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 266534 has been marked as a duplicate of this bug. ***