170128 - PAC: myIpAddress() does not update to network changes

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[benc]

from bug 79244: chase said in comment #10

There's another possibly relnote-worthy behavior, but I'm not entirely sure of
the scope of it.  If the address of the network interface changes (this is not
that uncommon for mobile users), myIPAddress() will continue to report the old
address.  This happens because we save dns.myIPAddress when the PAC is loaded
and then return that value every time.  I think this may run deeper as well --
I'm not sure if nsDNSService ever detects the change either.  I've been trading
email with a mobile user about this; I may just split it off into a separate bug.

Comment 1

[benc]

this would affect any number of our more sophisticated network users

Comment 2

[Stephen Gevers]

I'm surprised that there isn't more traffic surrounding this bug.  Maybe it is
because it is just simply annoying more than anything else.  I go between work
and home with my laptop, at each stop getting a DHCP assigned IP address.  I
have my proxy script set up to check the IP address to decide whether to return
DIRECT or the proxy address.  Works great except I have to shut down Mozilla
everytime I get a new address.  Anyway, I just didn't want anyone to think this
wasn't important to at least someone!

Comment 3

[Juan Lang]

Attachment: Clear myIPAddress when going offline..

so myIPAddress will get reread when going from offline to online.

Won't automatically change, except perhaps when combined with a fix to bug
76111.

Comment 4

[Juan Lang]

Attachment: Better patch

Clears when going offline, and again when going from offline to online. 
(Otherwise a myIPAddress check while in offline mode would cache the value
forever again.)

Comment 5

[Juan Lang]

cc me

Comment 6

[Juan Lang]

Comment on attachment 121700 [details] [diff] [review]
Better patch

Can't resist requesting review on a 5-line patch :)

Comment 7

[Darin Fisher]

Comment on attachment 121700 [details] [diff] [review]
Better patch

sr=darin

Comment 8

[Darin Fisher]

i think this bug is now fixed with the DNS rewrite.

myIPAddress does not exist anymore, but that aside... i think the underlying bug
is fixed.  now, whenever nsIDNSService::myHostName is accessed, we call
PR_GetSystemInfo, which calls into the OS to fetch the current hostname of the
local system.  DNS caching is also now limited to no longer than 1 minute, and
moreover when the user toggles the online/offline switch, we flush the entire
DNS cache.  so, i think we can say that this bug is fixed as a result of the
patch for bug 205726.

Comment 9

[Darin Fisher]

Barry Hathaway wrote me to say:

>I see from Bugzilla that you had worked on bug #170128 and now it is closed.
>I just recently installed Mozilla 1.6 and I still seem to see the same behavior
>with myIpAddress() - it always returns the same address. Any ideas how I can
get >either the current IP address or hostname of my Windows machine in
autoproxy.pac?
>Thanks in advance.

Upon further inspection of this problem, I think the problem has to do with the
fact that nsProxyAutoConfig.js only computes the value for myIP once (after the
PAC file has been loaded).

A workaround for this problem is to force reload the PAC file from the proxy
preferences panel.

Comment 10

[benc]

is this a matter of moving the code out of the onStopRequest into myIpAddress(),
or is it more complicated?

It sounds like we can call nsIDNSService::myHostName whenever we want, because
it is hooked in to cache (I think we changed myIpAddress() from a method to a
property a long time ago because we didn't have caching).

Comment 11

[benc]

UPDATE: Mozilla 1.7b
Mac and Linux seem to always return 127.0.0.1.

Comment 12

[Darin Fisher]

> is this a matter of moving the code out of the onStopRequest into myIpAddress(),
> or is it more complicated?

This doesn't make any sense to me.


> It sounds like we can call nsIDNSService::myHostName whenever we want...

Right, it is probably just a matter of modifying nsProxyAutoConfig.js such that
it always hits nsIDNSService to satisfy "myIP."

Comment 13

[Darin Fisher]

> > is this a matter of moving the code out of the onStopRequest into myIpAddress(),
> > or is it more complicated?
> 
> This doesn't make any sense to me.

I understand now... the answer I think is "yes."  I'm working on a patch now.

Comment 14

[Darin Fisher]

Attachment: v2 patch

Ok, this patch fixes two problems:

 (1) It makes myIpAddress() always talk to the DNS service, and
 (2) It eliminates the bogus single-level of caching in dnsResolve.

Comment 15

[Boris Zbarsky [:bzbarsky]]

darin, I'm not doing srs, remember?  If there's absolutely no one else qualified
to review this, I can try to take a look in a few days, but otherwise...

Comment 16

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

Comment on attachment 147702 [details] [diff] [review]
v2 patch

hm... this assumes the hostname stays the same.... can't DHCP assign you a
different hostname? or what if the user changes the hostname himself?

well, in any case, this is an improvement. r=me.

Comment 17

[Darin Fisher]

> hm... this assumes the hostname stays the same.... can't DHCP assign you a
> different hostname? or what if the user changes the hostname himself?

Yeah, good point.  I'll write up a better patch.

Comment 18

[Darin Fisher]

Attachment: v2.1 patch

revised per biesi's review

Comment 19

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

Comment on attachment 147738 [details] [diff] [review]
v2.1 patch

thanks

Comment 20

[benc]

Looks like a lot of functional changes, but will behave much better, as good as
we can considering the fact it can only return one IPv4 address.

So, I'm assuming the cache-of-one is removed b/c of the DNS rewrite?

What is also worth noting is that we get the IPaddress by doing a lookup on our
hostname, which is not perfect, but the best we can do... (if we enumerated the
interfaces, which would we return), because hostnames sometimes aren't set, or
are set incorrectly).

If your system returns 127.0.0.1, type nslookup $HOST (mac) or nslookup
$HOSTNAME (linux), if it returns an error, you know why. 

(putting all this here before I forget, and isn't worth filing a new bug b/c it
can't be fixed).

Comment 21

[Darin Fisher]

> So, I'm assuming the cache-of-one is removed b/c of the DNS rewrite?

yeah, that's right, and in fact the bugs mentioned in the comments had all been
fixed.

Comment 22

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

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

Comment 23

[Darin Fisher]

fixed-on-trunk

Comment 24

[Darin Fisher]

Comment on attachment 147738 [details] [diff] [review]
v2.1 patch

This is a low-risk patch that would be good to get on the 1.7 branch if time
permits.

Comment 25

[Mike Kaply [:mkaply]]

Comment on attachment 147738 [details] [diff] [review]
v2.1 patch

a=mkaply

Comment 26

[Darin Fisher]

fixed1.7

Comment 27

[benc]

verified 1.7: 20040524, Win 2K.

I'm not going to get to Mac or Linux soon, unless I get lucky.

The steps I'm using are:

using PAC:
http://www.mozilla.org/quality/networking/testing/PAC/myIpAddress.pac

view the javascript console. each accessed URL will cause the current result of
myIpAddress() to be logged.

click on any link. confirm IP address is correct.
go offline. click on any link. confirm IP address is 127.0.0.1
go online. click on any link. confirm the IP address is correct again.

Comment 28

[benc]

VERIFIED: Mozilla 1.7RC2, Mac OS X.
Same steps, although you have to reload PAC to update.

You also have to remember that the value returned comes from a lookup of
"hostname -s".

Comment 29

[Ivica Vujanic]

(In reply to comment #28)

I can confirm that this bug is present in FireFox 1.0 running on OSX 10.3.7.

myIpAddress() is always returning 127.0.0.1, regardless of the on-line /
off-line state. I assume it is a FireFox problem and not some wierd settings in
my OSX, as other browsers return correct address using the same call.

I believe this might be the same issue as #250249.

Comment 30

[benc]

Ivica:

What does hostname -s say? What happens if you telnet to that returend hostname?

Comment 31

[Loris Santamaria]

> If your system returns 127.0.0.1, type nslookup $HOST (mac) or nslookup
> $HOSTNAME (linux), if it returns an error, you know why. 
> 
[Loris.Santamaria@guasipati ~]$ nslookup $HOSTNAME
Server:         192.168.0.100
Address:        192.168.0.100#53

Name:   guasipati.pzo.open-world.com.ve
Address: 192.168.0.213

...but here lies the problem:

[Loris.Santamaria@guasipati ~]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 guasipati.pzo.open-world.com.ve guasipati localhost.localdomain  
localhost


And this is the default configuration in Fedora with DHCP enabled. It seems that
mozilla does not look th Ip address as "nslookup $HOSTNAME" but as "hostname -i"

Comment 32

[benc]

Lori, Ivica: necko does use the system calls for resolver, which in most cases
means using /etc/hosts. That is really not the topic of this bug, which was that
myIpAddress() needs to change when the underlying values change.

I'm going to verify and close up this bug, so I'm asking you to create a new bug
so we can address the problems there.