If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[meta] PAC: myIPAddress()

RESOLVED WONTFIX

Status

()

Core
Networking
--
major
RESOLVED WONTFIX
17 years ago
5 years ago

People

(Reporter: benc@chuang.net, Unassigned)

Tracking

({helpwanted, meta, relnote})

Trunk
Future
helpwanted, meta, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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

17 years ago
qa to me.

Dependent on 58030.
Depends on: 53080
QA Contact: tever → benc

Comment 2

17 years ago
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 timeless@mac.com 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...

Updated

17 years ago
Target Milestone: --- → mozilla0.9.3

Updated

17 years ago
No longer depends on: 53080

Comment 3

17 years ago
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

17 years ago
-->PAC bugs to Jussi
Assignee: neeti → jpm

Updated

17 years ago
Blocks: 79893

Updated

17 years ago
QA Contact: benc → pacqa

Comment 5

17 years ago
Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka
Assignee: jpm → serge

Comment 6

16 years ago
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 7

16 years ago
+ RELNOTE:

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

(am I documenting this one correctly?)
Keywords: relnote

Comment 8

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
tm -> 095
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

16 years ago
Target Milestone: mozilla0.9.5 → mozilla1.0

Comment 13

16 years ago
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)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 14

16 years ago
to default owner
Assignee: serge → new-network-bugs

Comment 15

16 years ago
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.
QA Contact: pacqa → benc

Comment 16

16 years ago
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

16 years ago
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

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

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

Comment 19

15 years ago
future
Target Milestone: mozilla1.0.1 → Future

Comment 20

15 years ago
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.
Target Milestone: Future → ---

Updated

15 years ago
Target Milestone: --- → Future

Comment 21

15 years ago
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

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

Comment 23

15 years ago
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

15 years ago
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

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

Comment 26

15 years ago
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

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

add:

alert(myIpAddress());

to your scripts that seem to misbehave.
Depends on: 191715
Keywords: meta
Summary: PAC: myIPAddress() → [meta] PAC: myIPAddress()

Updated

14 years ago
Depends on: 242337
Depends on: 246872

Comment 28

13 years ago
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

13 years ago
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.

Updated

12 years ago
Depends on: 231115

Comment 30

12 years ago
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

12 years ago
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

9 years ago
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

8 years ago
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

7 years ago
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

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

Comment 36

7 years ago
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).
tracking bug has been exhausted to the extent it is not a dup of 347307 or part of a pac2 effort.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.