336235 - myIpAddress() may return an obsolete value

Status: RESOLVED DUPLICATE of bug 347307

(Core :: Networking, defect)

Description

[fieldhouse]

User-Agent:       Opera/8.54 (Windows 98; U; en)
Build Identifier: 1.5.0.1,2

In Windows XP SP2 with 1.5.0.1, myIpAddress() is incorrectly caching the returned value.

Eg, machine has 2 LAN interfaces and a WLAN. Normally only 1 is connected at once and addresses are assigned by DHCP. A local PAC file is used to switch between office (proxy) and other (DIRECT) environments.

After suspending while connected to WLAN and then waking while connected to LAN#2, the IP returned by myIpAddress() is that associated with the WLAN which is now reported by ipconfig as 'Media disconnected'. The newly acquired DHCP address for LAN#2 is ignored, even after reloading the PAC using the button in Tools>Options>General>Connection Settings.

Reproducible: Always

Steps to Reproduce:
1. Have a Windows XP SP2 installation with 2 LAN interfaces and Firefox 1.5.0.2, and only one of the interfaces connected. Probably easiest if the LAN is configured for DHCP. Use ipconfig to display the IP address configuration.

2. Use a local PAC script that calls myIpAddress() and reports the returned value using alert().

3. Make a connection and observe the PAC-alert line in the JavaScript console.

4. Connect the 2nd LAN interface instead of the first; then run ipconfig again.

5. Repeat #3, optionally after exercising the PAC reload function.

Actual Results:  
1. ipconfig -> IP#1
3. PAC-alert: IP#1
4. ipconfig -> IP#2
5. PAC-alert: IP#1

Expected Results:  
1. ipconfig -> IP#1
3. PAC-alert: IP#1
4. ipconfig -> IP#2
5. PAC-alert: IP#2

Even given that myIpAddress() is a fundamentally flawed and possibly
inconsistently specified interface, 

a) it's good to cache the return value;

b) *but only if* the cached value gets invalidated appropriately;

c) reloading the PAC should certainly invalidate the cache;

d) if there's no other way of invalidating or verifying the cached value, maybe there should be a time limit on its validity.

Originally reported against 79244; new bug opened in response to comment from [e-mail].

Comment 1

[fieldhouse]

Continues to be seen with 2.0.0.9.

In nsProxyAutoConfig.js, we see:

function myIpAddress() {
    try {
        return dns.resolve(dns.myHostName, 0).getNextAddrAsString();
    } catch (e) {
        return '127.0.0.1';
    }
}

According to NSPR docs, the 2nd parameter 0 to the resolve method means 'use cached value'. If this para meter <> 0, the cache is flushed. The cache appears to be local to each instance of nsIDNSService, since calling dns.resolve(dns.myHostName,1) from the console has no effect on the PAC function.

I experimented with a solution whereby a function dnsFlushMyIp would be provided in the sandbox and called by the nsProxyAutoConfig's init method. The idea was to allow the user to flush the cache by using the 'Reload' button in Tools>Options>Advanced>Network>Settings. However Reload doesn't seem to trigger the init method.

Comment 2

[fieldhouse]

Now with 2.0.0.11, I am testing the following in nsProxyAutoConfig.js:

- declare 'var _myIpAddressWhen = null;' at the same scope as the variable dns;

- replace function myIpAddress() as below, to give a 5 minute timeout on the cached value:

function myIpAddress() {
    try {
	var now = (new Date()).valueOf();
	var bFlush = 0;
	if (!_myIpAddressWhen || ((now - _myIpAddressWhen) > 300000 /* ms */)) {
	    _myIpAddressWhen = now;
	    bFlush = 1;
	}
        return dns.resolve(dns.myHostName, bFlush).getNextAddrAsString();
    } catch (e) {
        return '127.0.0.1';
    }
}

While this is not very pretty, I can see that the cached value is being flushed and therefore it should address the problem. Who owns nsProxyAutoConfig.js? What is an acceptable value of the timeout -- 1 minute, 5 minutes, ...?

Comment 5

[fieldhouse]

I'm not convinced that this and https://bugzilla.mozilla.org/show_bug.cgi?id=692725 are actually dups of https://bugzilla.mozilla.org/show_bug.cgi?id=347307. However it isn't currently a problem for me (liberation from company proxy) and some time has passed, so let's see what new releases with the rewritten nsProxyAutoConfig for https://bugzilla.mozilla.org/show_bug.cgi?id=769764 reveal.

Incidentally it's great that this rewrite is being done - I've certainly observed GUI hangs that could well be down to synchronous DNS resolution in proxy config.
/df

Comment 6

[Patrick McManus [:mcmanus]]

df - you're right that they are only dups in the sense that the patch in 347307 should fix them too because, I believe, it no longer caches the member variable in DNS that was causing this particular problem.