79244 - [meta] PAC: myIPAddress()

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[[e-mail]]

From bug 58030:

------- Additional Comments From Mike Shaver 2001-03-22 09:47 -------

review comments:
  - make MyIPAddress an attribute, not a method
  - what does ``my'' mean?  What happens for machines with multiple IP addresses
    (like, say, _every_ Linux box in the universe)?  I'd prefer
    ``localAddress'', but I also want to know what happens in that case.

For 0.8.1, let's just rip out the localhost->local-hostname crap and leave the
rest of this patch out.


------- Additional Comments From Gagan 2001-03-22 10:27 -------

shaver: I like the idea of making myIPAddress an attribute. I'll submit a new
patch soon. As for the case of multiple IP addresses-- AFAIK we use the default
(or primary) hostname to get to the IP address.
blizzard: the only caller of the "myIPAddress" functionality is in the PAC (bug
53080) and I will make sure I add the corresponding patch there as well. Thanks
for the sr.

Comment 1

[benc]

qa to me.

Dependent on 58030.

Comment 2

[benc]

further comments:


------- Additional Comments From Akhil Arora 2001-01-25 20:39 -------

Thanks for picking up this bug, Denis. On the topic of the myIpAddress, the
current implementation is very inefficient, it does a DNS lookup of localhost
for every URL. It would be preferable to cache the value.


------- Additional Comments From [e-mail] 2001-01-25 20:56 -------

erm. Shouldn't we cache the array of localhost ip's and their understanding of
netmasks?  I have 3 ips assigned to my box, and i do occasionally use all of
them.

Oh, and can anyone comment on the difficulty of supporting ipv6 ips?


------- Additional Comments From Denis Antrushin 2001-01-26 08:13 -------

As for myIPAddress(), "localhost" is resolved into 127.0.0.1, i.e. loopback
interface, while we need a way to get IP address(es) of 'real' interfaces....
I suspect we can't get it from inside sandbox...

Comment 3

[Denis Antrushin]

Current implementation is to set local ip address from nsIDNSService.
Actually it's an attribute now. It's wrapped into function call
only for backward compatibility with existing PACs

Comment 4

[neeti]

-->PAC bugs to Jussi

Comment 5

[Jussi-Pekka Mantere]

Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka

Comment 6

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 7

[benc]

+ RELNOTE:

myIPAddress() returns 127.0.0.1 instead of the IP of your network interface.

(am I documenting this one correctly?)

Comment 8

[Chase Tingley]

Actually, I think that's an overly gloomy relnote.  On a machine with a single
network interface, myIPAddress() should correctly return the address of that
interface.  (At least, I *believe* this works.  It seems to on linux.)  If for
some reason the address is unavailable or can not be determined, 127.0.0.1 will
be used (this is new in bbaetz's fix for bug 80363). 

We run into trouble when there are multiple network interfaces -- we only return
one.

Comment 9

[benc]

I didn't submit this release note text yet, so let's draft a new text block.

Would you like to try your hand at writing a release note? :)

Comment 10

[Chase Tingley]

Something like:

-//-

On a machine with multiple network interfaces, myIPAddress() will only return
the address of one of them.  

-//-

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 11

[benc]

Make a new bug. Is the reporter using Linux? That is where the DNS service is
not making people happy. There is a fix in the works.

I'll try to do a relnote push later this week.

Comment 12

[serge (gone)]

tm -> 095

Comment 13

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 14

[serge (gone)]

to default owner

Comment 15

[benc]

qa to me.

Chase: 

I'll look into that changing IP address problem when I do some connectivity
testing this month.

So, is there anything here that really needs fixing, or is it all really a
documentation aspect? Nobody has reported a broken PAC file and been linked to
this bug.

Comment 16

[Vladislav Kurz]

I have a few comments to myIpAddress(), I found after hard time debugging 
why my PAC script does not work.

The address it returns is probably the same as Linux command 'hostname -i'.
I.e. it tries to resolve the hostname of the computer. That's wrong because 
this is often arbitrary name given by user and does not exist in DNS, or 
resolves to 127.0.0.1 using /etc/hosts. Mozilla should give IP address of 
the network interface, and should not care about domain names at all.

Yes there is a question which interface if there are more, I suggest to use 
that one that will be used to send HTTP request, or the one with default 
route.

Other thing is that the function must reflect if the IP address has changed.
E.g. when the user moves with notebook to another network without closing 
Mozilla.

P.S. Does anyone know how to comfortably debug PAC scripts. As far as I 
know any browser just silently ignores any errors in PAC or the whole 
script and goes DIRECT. And when I include the script into web page and try 
to run the function it can't find special PAC functions like 
myIPaddress()...

Comment 17

[benc]

In my opinon, we should be doing ifconfig -a

In Mac OS X, you could do:

ifconfig -a, then grab any dotted quad octets after "inet"

I think interfaces that are "DOWN" should be ignored.

Comment 18

[benc]

+helpwanted - serge owned this, but did not re-assiing this to a person.
cc: neeti

Chase's comments in #10 are now bug 170128.

Comment 19

[Doug Turner (:dougt)]

future

Comment 20

[benc]

http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html#myIpAddress

myIpAddress()
Returns the IP address of the host that the Navigator is running on, as a string
in the dot-separated integer format.
Example:

myIpAddress()
would return the string "198.95.249.79" if you were running the Navigator on
that host.

-future, sending to eng triage.
A PAC file w/ some debug statments or clever structuring could determine the
current behavior.

Some work probably needs to be done, based on comment #10.

Comment 21

[Sam Etler]

This seems to be an issue as well with Camino (MacOS X 10.2.4, 6I32, Camino 0.7,
Build ID 2003030613).  Either that or I'm doing something wrong (entirely
possible, my Javascript isn't exactly what I would call good).

I have in my proxy.pac file:

        if (dnsDomainIs(host, ".tellme.com") &&
            isInNet(myIpAddress(), "209.157.156.0", "255.255.254.0")) {    
                return "DIRECT";
        }

This fails and goes through to the next if:

        if (dnsDomainIs(host, ".tellme.com")) {
                return "PROXY 127.0.0.1:3128"; 
        }

When I replace myIpAddress() with "209.157.156.150" which I've verified with an
ifconfig -a is the IP address assigned to the interface en1, it works.  Doh! 
This would be such a cool thing if it worked.

Comment 22

[Darin Fisher]

sam: sounds to me like you might be seeing bug 191715.

Comment 23

[Sam Etler]

Hmm... possibly.  I don't fully understand a lot of the talk in Bug 191715. 
However it seems to be talking a lot about the isInNet() function.  The thing
about this problem is that I also tried something like:

if (dnsDomainIs(host, ".tellme.com") &&
    myIpAddress().substring(0, 7) == "209.157") {
        return "DIRECT";
        }
        else {
             return "PROXY 127.0.0.1:3128";
        }

And it wasn't working.  I thought perhaps I didn't understand the .substring()
function, and perhaps I still don't, but when I set a variable s to
"209.157.156.150" and tested against s.substring(0, 7) == "209.157" it worked. 
So it seemed to me from that test that it could be directly correlated to either
a problem with myIpAddress() or some stupidity on my part.

Comment 24

[Darin Fisher]

right, that wouldn't work either.  the issue is that myIPAddress is returning an
IPv6 address literal, which does not look like xxx.xxx.xxx.xxx, so your checks fail.

Comment 25

[Sam Etler]

That's very amusing.  OK thanks for pointing that out.  I guess I'll start
following Bug 191715 closer.

Comment 26

[Henry]

I just wanted to note that this bug still seems to be present with mozilla 1.4a
I am using linux and have only one interface as shown below, yet when using the
javascript debugger a call to myIpAddress() [is the fact that there is no
capital 'P' important?] returns 127.0.0.1.
note that myIpAddress() returns a correct value for mozilla 1.3 on my other
windows 2000 machine

hjs@bblfish/tmp> /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:10:A4:FA:04:5C
          inet addr:130.144.160.179  Bcast:130.144.160.255  Mask:255.255.255.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:372477 errors:0 dropped:3 overruns:0 frame:0
          TX packets:33375 errors:0 dropped:0 overruns:0 carrier:1029
          collisions:0 txqueuelen:100
          RX bytes:75103911 (71.6 Mb)  TX bytes:3322674 (3.1 Mb)
          Interrupt:3 Base address:0x300

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:124 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8937 (8.7 Kb)  TX bytes:8937 (8.7 Kb)

Comment 27

[benc]

PAC supports alert (to javascript console), so this is now much easier to
understand.

add:

alert(myIpAddress());

to your scripts that seem to misbehave.

Comment 28

[Jason Merrill]

The combination of 235853 and the issue that myIpAddress causes two attempts to
look up my hostname for every URL has made Firefox and Mozilla useless for me on
some networks; I feed the browser a URL and it hangs for minutes at a time.  As
with 235853, the lookups that myIpAddress does seem to be resolved
synchronously, so if they don't return in a timely fashion the browser just hangs.

As another poster mentions, my hostname usually has no connection to my IP
address, since I'm on a laptop that gets attached to arbitrary networks.  I
agree that myIpAddress should look at the actual interfaces, not try to do DNS
resolution.  Just returning the first non-loopback interface (or perhaps the one
with the best metric) makes sense to me.

I'm glad to finally learn what the source of the problem is, though; I can
comment out the uses of myIpAddress in my PAC script as a workaround.

Comment 29

[benc]

I suppose, after further contemplation, the interface that points to the default
gateway should be used for the ipaddress. That would make sense, but also
probably require platform-specific code to implement.

Comment 30

[fieldhouse]

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

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.

In 1.5.0.2, the same problem occurs when switching from LAN#2 to LAN#1, ie, myIpAddress() reports the LAN#2 address rather than the new LAN#1 address (in this case, as the addresses have the same prefix, it happens that this has no effect on FindProxyForURL() return value). This is a rather simpler test case.

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.

Comment 31

[benc]

Please file a separate bug for this problem. This bug has a history of having too much discussion. It is a tracking bug.

Comment 32

[A. Craig West]

This bug has been open since 2001, and still hasn't been fixed? It makes PAC files useless in most cases on Linux, as the primary reason for using a PAC file is to choose proxy's based on IP address

Comment 33

[Stephen Butcher]

There are a few other bugzilla reports for problems with myIpAddress().
https://bugzilla.mozilla.org/show_bug.cgi?id=347307
https://bugzilla.mozilla.org/show_bug.cgi?id=336589
https://bugzilla.mozilla.org/show_bug.cgi?id=304822
https://bugzilla.mozilla.org/show_bug.cgi?id=299414

I have confirmed this problem on:
Firefox 3.0.13 on Ubuntu 8.10, myIpAddress() returns: 127.0.1.1
Firefox 3.5.3 & 3.6 on Mac OS X (Snow Leopard), myIpAddress() returns: 127.0.0.1

As a workaround for these platforms (Mac OS + *nix), we are using Python to generate a PAC file. Unfortunately, the use of the python script is pushing up the load on our web server. 
A resolution to this long standing bug would be greatly appreciated.

Comment 34

[Dave Dykstra]

I was having this problem on MacOSX Snow Leopard 10.6.4 with Firefox 3.6.6, but eventually I found out that it was related to the fact that a search domain I had manually entered in the Network DNS preferences did not exactly match the domain that I received from DHCP.  If I either deleted the manual search domain (which overrides the default one) or put in both my my preferred search domain and the default one manually, firefox returned the correct address rather than 127.0.0.1.  Note that it did take a while, roughly 10 minutes for firefox to notice the change.

Comment 35

[Dave Dykstra]

I should have been more clear that the DNS search domain is set in System Preferences, not in Firefox's own preferences.

Comment 36

[David von Oheimb]

It seems to me that bug 347307 contains a hint how to fix/workaround this bug on Linux: delete from /etc/hosts all lines containing the machine hostname, e.g. "127.0.1.1 mymachine" (while the line "127.0.0.1 localhost" can and should stay).

Comment 37

[Patrick McManus [:mcmanus]]

tracking bug has been exhausted to the extent it is not a dup of 347307 or part of a pac2 effort.