Closed Bug 400309 Opened 17 years ago Closed 12 years ago

myIpAddress returns bogus value if multiple interfaces are present

Categories

(Core :: Networking, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 347307

People

(Reporter: brianr-bugzilla.mozilla.org, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

When calling myIpAddress() from within a proxy.pac file on a Windows XP PC with IPv6 enabled, it returns "::1". It would be reasonable to return the IP address of the interface through which the proxy.pac file was downloaded. 

Reproducible: Always

Steps to Reproduce:
1. Enable IPv6 on a Windows XP PC. 
2. Create minimal proxy.pac file:
function FindProxyForURL(url, host) {
alert(myIpAddress());
return "DIRECT";
}
3.Set firefox to use this proxy.pac

Actual Results:  
See lines like "PAC-alert: ::1" in the error console

Expected Results:  
See the actual ipv4 or ipv6 of the machine. Ideally it would be the address of the interface used to fetch the proxy.pac file.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
It appears that on ipv4 machines with multiple interfaces (for example, a wifi nic and a wired nic), the myIpAddress() function can return the address of an interface that won't actually be used for http requests. For example, if default route points out the wired nic and the user attempts to access a site which is reached via the default route, the myIpAddress() function may still return the address of the wifi nic. 
Summary: myIpAddress returns bogus value if IPv6 Enabled → myIpAddress returns bogus value if multiple interfaces are present
In fact, it may even return the (former) address of the wifi nic when ipconfig reports 'media disconnected'. See Bug 336265, for which brianr's second comment appears more relevant.

The heuristic of using "the address of the interface used to fetch the proxy.pac file" sounds good -- if that address is accessible from the PAC sandbox. But the file may be a local file, in which case the heuristic fails anyway.
Whiteboard: dupeme
I'm getting this too, 

alert(myIpAddress());

in my autoconfiguration file yields

PAC-alert: fe80::acaa:3d55:ea51:8b1b%21

even when I turn off IPv6 on all my network interfaces.  (did not reboot)

This is with Firefox 3.5.5, Windows 7 32 bit.
Hi,

Recenly, I've tested about this problem with changing Windows7's registry parameter: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents (DWORD32).  With this registry, usage of IPv6 on Windows can be disabled.  (Please refer http://support.microsoft.com/kb/929852/en in detail.)

On Windiws7, IPv6 is enabled and it can't be completly disabled even if you disable TCP/IPv6 with "local network connection".  And there are two types of IPv6 network connection: native interface (normall LAN, WiFi) and tunnling interface.

Here is return value of myIpAddress() with each registry variable on Windows7 with no IPv6 connection.

0 (or no registry key, default): Link local IPv6 address
0x01: Link local IPv6 address
0x10: Link local IPv6 address
0x11: IPv6 loopback (::1)
0x20: IPv4 address
0xffffffff: IPv4 address

Each registry value means:

0x01: Disable IPv6 on tunneling interraces
0x10: Disable IPv6 on native interfaces
0x11: Disalbe IPv6 on tunneling and native interfaces
0x20: Change prefix policy to prefer IPv4 (::ffff:0:/96)
0xffffffff: Disalbe IPv6 on all interfaces except loopback

It seems that Firefox simply prefer IPv6 if any of IPv6 address is available and it dosen't care for IPv6 address's prefix; link local or loopback.

Firefox should not use these addresses:

* IPv6 link local address since it isn't specify the subnet of host.
* IPv6 loopback address since it isn't specify the subnet of host.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Whiteboard: dupeme
You need to log in before you can comment on or make changes to this bug.