Closed Bug 336589 Opened 18 years ago Closed 12 years ago

myIpAddress in PAC files can return 127.0.0.1 instead of the real used IP if a matching entry is found in /etc/hosts

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
minor

Tracking

()

RESOLVED DUPLICATE of bug 347307

People

(Reporter: marchand, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.2 (like Gecko) Kubuntu 6.04 Dapper
Build Identifier: Debian Sarge 1.0.4

Hi,

while debugging my PAC script, I noticed that if for example my /etc/hosts contains :
127.0.0.1 localhost mymachineshortname

and if in my PAC script there is for example a :
if (isInNet(myIpAddress(), "a.b.c.d", "w.x.y.z"))
this condition will fail to match because myIpAddress will (well I guess) use 127.0.0.1 instead of eth0's IP.

removing mymachineshortname from /etc/hosts fixes the problem and the 'if' works as expected.
ok, it's bad to have mymachineshortname in /etc/hosts I guess, but sadly this was done automatically by my debian installer, and I believe it can happen on many other linux/unix.
I think myIpAddress should never be allowed to return 127.0.0.1 when the real connexion occurs on a real network (probably a DNS solver issue).

Cheers,
Mik


Reproducible: Always

Steps to Reproduce:
1. create a PAC file with for example :
function FindProxyForURL(url, host)
{
        if (isInNet(myIpAddress(), "10.0.0.0", "255.255.255.0")) {
		//direct or a real usable proxy
		return "DIRECT";
	}
	//that one should not work, so you can see that firefox can't load the webpage ;)
	return "PROXY a_wrong_ip_address:a_wrong_port;
}
2.use a client with firefox on network 10.0.0.0/24, and use the proxy.pac
3.add your client's short name to /etc/hosts as address 127.0.0.1


Actual Results:  
try to open a webpage with firefox, it will fail.


Expected Results:  
you should have been able to browse the web :)

workaround :
remove the entry in /etc/hosts,
try to open a webpage again (maybe reload the proxy.pac first/restart firefox), it should work this time.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → Trunk
Can you reproduce this with the latest Mozilla build of Firefox (1.5.0.3)?
in my sleepy and not so educated opinion, it seems to me that your pac is bad. it seems more reasonable that you should handle the 127.* and 169.* cases.

i'm starting to play w/ dapper, so i'm going to get some firsthand experience.

fwiw, you could do this:
if( isPlainHostName ( host )) return "DIRECT";

I suspect that line is designed to handle your case. -- that's actually the first non trivial line in a pac i saw.

for example the guys in redmond use it: http://www.microsoft.com/technet/prodtechnol/ie/ieak/techinfo/deploy/60/en/corpexjs.mspx?mfr=true

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

I'd point to the squid-cache examples, but most of their js won't compile, and it seems that whatever bug reports i've considered sending in the past haven't made it, so i'm going to try to file a bug against them instead of telling you to look there :(.
you did not well understand I think.
the problem is not to filter 127.* in the PAC file, I agree that it needs to be handled,
the real problem is that firefox "pretends" to use 127.0.0.1 (see myIpAddress() documentation) as its own client IP whereas it _actually_ uses a real public and routed IP to connect to the proxy ;)

Mik

(In reply to comment #2)
> in my sleepy and not so educated opinion, it seems to me that your pac is bad.
> it seems more reasonable that you should handle the 127.* and 169.* cases.
> 
> i'm starting to play w/ dapper, so i'm going to get some firsthand experience.
> 
> fwiw, you could do this:
> if( isPlainHostName ( host )) return "DIRECT";
> 
> I suspect that line is designed to handle your case. -- that's actually the
> first non trivial line in a pac i saw.
> 
> for example the guys in redmond use it:
> http://www.microsoft.com/technet/prodtechnol/ie/ieak/techinfo/deploy/60/en/corpexjs.mspx?mfr=true
> 
> see
> http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html#isPlainHostName
> 
> I'd point to the squid-cache examples, but most of their js won't compile, and
> it seems that whatever bug reports i've considered sending in the past haven't
> made it, so i'm going to try to file a bug against them instead of telling you
> to look there :(.
> 

(In reply to comment #1)
> Can you reproduce this with the latest Mozilla build of Firefox (1.5.0.3)?
> 

I will try tomorrow when I am back at work :)
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414

Mozilla 1.7.13 under Mac OS X

with the .pac:
function FindProxyForURL(url, host) {
alert("my IP: " + myIpAddress());
return "DIRECT";
}

still outputs in the javascript console "PAC-alert: my IP: 127.0.0.1"
Benoît, as this bug isn't marked fixed yet, that's not really a surprise. Also, 1.7.13 is a really old version...
sorry Christian for the noise...

I overreacted when reading your comment "bug 347307 should fix this" and the thread about the creation a new function giving an enumeration of available IP addresses

this new function will be fine, but what about first fixing the myIpAddress() function to return what ever IP available but not the obviously unuseful 127.0.0.1?

again sorry for this naive comment, just the point of view of a simple user, not a coder
the code doesn't know of any other IP currently. that bug will change that.
No longer depends on: 347307
Depends on: 347307
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.