Closed Bug 559664 Opened 14 years ago Closed 12 years ago

Pac file function myIpAddress() returns Link local IPv6 address instead of correct IPv6 address

Categories

(Core :: Networking, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 347307

People

(Reporter: f.herbert, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7
Build Identifier: 3.6.3 

Since Firefox insists on sending an IPv6 address, then it needs to send the correct one. 

On a windows 7 client with the following ipconfig:
   IPv6 Address. . . . . . . . . . . : 2001:4530:2:904:f5d4:a125:102a:da24
   Temporary IPv6 Address. . . . . . : 2001:4530:2:904:acdd:1080:6e03:e56f
   Link-local IPv6 Address . . . . . : fe80::f5d4:a125:102a:da24%11
   IPv4 Address. . . . . . . . . . . : 130.123.130.233

The IP address returned by Firefox using the PAC file function myIpAddress() is fe80::f5d4:a125:102a:da24%11 instead of 2001:4530:2:904:f5d4:a125:102a:da24. This gives us no way of finding out where the machine is by subnet.

Chromium have found this issue and fixed it here by making the myIpAddress() function only return IPv4 addresses:
http://code.google.com/p/chromium/issues/detail?id=24641

Here is a thread of other Firefox users having the same issue:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=tr&comments_parentId=259063&forumId=1

Also Internet Explorer have resolved this by creating a separate IPv6 set of functions:
http://blogs.msdn.com/wndp/archive/2006/07/18/IPV6-WPAD-for-WinHttp-and-WinInet.aspx

As IPv6 becomes more widely used, this issue is going to affect more and more Firefox users (only when using a PAC file)



Reproducible: Always

Steps to Reproduce:
1. Create PAC file with the following line: alert ("Ip Address" + myIpAddress());
2. On Windows vista with a valid IPv6 address, point firefox to this PAC file
3. Check error console, you will see the IPv6 link local address in the alert instead of the correct IPv6 address
Actual Results:  
The link local IPv6 address is returned when the myIpAddress() function is called in the PAC file.

Expected Results:  
The correct IPv6 address to be returned when the myIpAddress() function is called (or the IPv4 address)
Note I have tested this on OS X 10.6.3 (10D573) with Firefox 3.6.3 and myIpAddress() returns the IPv4 address (my machine has an IPv6 address as well).
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

You can also try to reproduce in Firefox 4 Beta 8 or later, there are many improvements in the new version, http://www.mozilla.com/en-US/firefox/all-beta.html
Whiteboard: [CLOSEME 2011-1-30]
I am still seeing this issue in Firefox 3.6.13 in safe mode and also in Firefox 4 beta 8 in safe mode.
Maybe it's fixed by bug 614526 ?
(In reply to comment #4)
> Maybe it's fixed by bug 614526 ?

Bug 614526 is for Mac OS, this bug is for Windows 7
It was filed by a Mac (as most people at mozilla use this for day-to-day work), but the getaddrconfig() cal exists on multiple platforms.  If you go to <http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prnetdb.c#2044> (which is were bug 614526 was fixed), you see a comment about Windows. Bug 614526 also talks a lot about Windows. 

Anyway, that's not the point. What's important is that it might be fixed in the latest nightly build.
No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
confirming with Seamonkey trunk on win7/32
PAC-alert: fe80::78a9:2801:c6c4:2345%17

   Verbindungsspezifisches DNS-Suffix: lan
   IPv6-Adresse. . . . . . . . . . . : 2001:4dd0:f8c6:0:78a9:2801:c6c4:2345
   Temporäre IPv6-Adresse. . . . . . : 2001:4dd0:f8c6:0:3518:1ef2:5c3d:fc1d
   Verbindungslokale IPv6-Adresse  . : fe80::78a9:2801:c6c4:2345%17
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.30
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::223:cdff:fe14:d02e%17
                                       192.168.0.254
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Whiteboard: [CLOSEME 2011-1-30]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → Trunk
Confirmed on Firefox 7.0.1 running under Windows 7.

MyIpAddress returns link-local address even though IPv6 is not in active use. If IPv6 is disabled on the NIC properties, MyIpAddress returns IPv6 address ::1.

Internet Explorer 9 works OK with the same PAC file.
Tested and confirmed on Firefox 10.0 beta running under Windows 7 Pro SP1 32-bit. 
("Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0")

IPv6 disabled on the NIC, and using alert("IP Address " + myIpAddress());  
returns "PAC-alert: IP Address ::1"

IE 8 works with the same PAC.

Note also that the "set network.dns.disableIPv6 to true" workaround is successful, but undesirable.

see also bug 629666 

and for proposed myIpAddressEx and dnsResolveEx enhancements, see bug 558253
I confirm that this bug exists (and is very annoying!) on Firefox 11.0 under Windows 7.
I also confirm this bug. The fix is easy:

Change line 84 of source/netwerk/base/src/nsProxyAutoConfig.js

from
return dns.resolve(dns.myHostName, 0).getNextAddrAsString();
to
return dns.resolve(dns.myHostName, RESOLVE_DISABLE_IPV6);
Sorry, I mis pasted. I should be:

from
return dns.resolve(dns.myHostName, 0).getNextAddrAsString();
to
return dns.resolve(dns.myHostName, RESOLVE_DISABLE_IPV6).getNextAddrAsString();
in response to comment #10: A returned localhost address is a different bug.
Mikey: Wouldn't that disable the IPv6 link-global response ?
That is _not_ this bug. Please reread the summary of this bug...
Matthias. You are right I miss read the bug report.

However MyIpAddress() should never return an IPv6 address because it will break existing PAC files which rely on it returning an IPv4 address. Standard behavior in PAC files is to use something like:
 
if ( isInNet(MyIpAddress(), "10.10.0.0", "255.255.0.0") ) { return "PROXY proxy:port";} .

This will fail if MyIpAddress() returns an IPv6 address. Other browser makers have also seen this problem and have implemented extended functions to deal with IPv6 like MyIpAddressEx() exactly to prevent breakage of existing configurations.
Firefox should follow this practice since it is the only browser that breaks in regard to PAC files if IPv6 is active on the host.

See also:
http://code.google.com/p/chromium/issues/detail?id=25407
http://msdn.microsoft.com/en-us/library/windows/desktop/gg308478(v=vs.85).aspx

So probably this bug should be closed as not returning the right IPv6 address is not the problem. MyIpAddress() returning IPv6 address at all is the problem.
I dug a little further and there is already a request for MyIpAddressEx() in bug 558253. People wanting to implement PAC files for IPv6 should register with that bug. 

comment #1 said: "Since Firefox insists on sending an IPv6 address...". Which to me sound like sending an IPv4 address would be his preferred solution. 

comment #9 and comment #10 said: "IE 8 works with the same PAC." Indicating that conforming to the way Microsoft has implemented it is preferred. That also means only sending IPv4 addresses.
Please stop commenting in this bug. Your comments are offtopic.
Nobody seems work on PAC in the last few years and if someone starts in this area he or the Necko Module owner will decide what to do with IPv6. We have different bugs for returning 127.0.0.1, ::1, link-local and for IPv6 extensions
Status: NEW → RESOLVED
Closed: 13 years ago12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.