Re-enabling IPv6 on mac breaks SOCKS support for localhost

VERIFIED FIXED in mozilla1.9beta3

Status

()

P1
normal
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: bugzilla, Assigned: david)

Tracking

({regression})

Trunk
mozilla1.9beta3
x86
Mac OS X
regression
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
Turning on ipv6 on again on mac (Bug 408881) broke SOCKS proxy support.  With SOCKS enabled and configured with a host and port, pages do not load and page info shows about:blank as the location.  (I did have pages load a few times but I think that was just because I neglected to nuke the cache; it is stored separately from the profile on mac)

STR:
run `tcpdump -i lo0 'port 8000'` as root and watch for output after the initial couple lines
make a new profile
rm -rf "$profilepath"/* && cat > "$profilepath"/prefs.js <<'EOF'
user_pref("network.proxy.socks", "localhost");
user_pref("network.proxy.socks_port", 8000);
user_pref("network.proxy.type", 1);
EOF
start firefox with said profile

ER:
default homepage and firstrun page appear in tabs, load completely

AR:
2 blank tabs with page info showing location about:blank (a couple times real content showed but that it likely because I forgot to nuke the profile's cache)

throw in
user_pref("network.dns.disableIPv6", true);
in addition and everything works fine.

regression range:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1199516820&maxdate=1199518979

Note this is broken with local and remote dns queries. (network.proxy.socks_remote_dns)
Flags: blocking1.9?
(Reporter)

Comment 1

11 years ago
Forgot to mention: tcpdump results in no additional output with broken SOCKS and plenty of output with functional SOCKS, indicating that no connection is made (or refused) and eliminates the possibility of this being dependent on the proxy server.

Comment 2

11 years ago
Does socks work if you configure the host as 127.0.0.1 instead of localhost?

If so, what is happening is probably this: on the Mac with IPv6 enabled, "localhost" resolves to ::1. Firefox is connecting to "localhost", i.e. ::1, and the SOCKS proxy running on your local host is IPv4-only, so the connection is refused.

If that's the case, then this bug is arguably invalid: you have configured Firefox to use a SOCKS proxy (localhost) that does not exist (since, if IPv6 is enabled, "localhost" means "::1").

Note that this is not the case under Linux, where localhost is always 127.0.0.1 and ::1 is ip6-localhost. I remember wondering about the reason for that at the time :)
(Reporter)

Comment 3

11 years ago
(In reply to comment #2)
Yup, that seems to be it.  I guess this is really just "SOCKS chokes on IPv6 proxy server".
Severity: major → normal
well does your socks server listen on ::1? Try:

netstat -ln | grep 8080

What does that show?

Comment 5

11 years ago
Jeremy, what does your /etc/hosts file look like? If localhost maps to both 127.0.0.1 and ::1, then it's reasonable to assume that the SOCKS proxy code should retry over IPv4 if the IPv6 connection fails.
(Assignee)

Comment 6

11 years ago
Slightly more verbose note re Lorenzo's comment;

On OS X 10.4, it appears that despite the intelligence in getaddrinfo for stubbornly not returning IPv6 addresses unless the system has successfully connected to an IPv6 network since the last reboot, loopback always returns
both the IPv4 and the IPv6 address.

This is probably because:

1. /etc/hosts on OS X 10.4 contains explicitly 127.0.0.1 and ::1

2. Even if you "ip6 -x" to remove all IPv6 addresses on all interfaces, the ::1
   address is not removed from loopback

Really, if SOCKS is listening only on 127.0.0.1, then the SOCKS code should
quickly fail to connect to ::1 then successfully connect to 127.0.0.1.  But
as per your comment above, it looks like it doesn't.
(Assignee)

Comment 7

11 years ago
BTW, is this a test case or a real use case?  Using a SOCKS proxy on localhost seems like a fairly unlikely thing to want to do.

Comment 8

11 years ago
The problem seems to be the code at http://lxr.mozilla.org/seamonkey/source/netwerk/socket/base/nsSOCKSIOLayer.cpp#613:

    // Sync resolve the proxy hostname.
    PRNetAddr proxyAddr;
    {
        nsCOMPtr<nsIDNSService> dns;
        nsCOMPtr<nsIDNSRecord> rec; 
        nsresult rv;

        dns = do_GetService(NS_DNSSERVICE_CONTRACTID, &rv);
        if (NS_FAILED(rv))
            return PR_FAILURE;

        rv = dns->Resolve(proxyHost, 0, getter_AddRefs(rec));
        if (NS_FAILED(rv))
            return PR_FAILURE;

        rv = rec->GetNextAddr(info->ProxyPort(), &proxyAddr);
        if (NS_FAILED(rv))
            return PR_FAILURE;
    }
[...]
    // Connect to the proxy server.
    status = fd->lower->methods->connect(fd->lower, &proxyAddr, connectWait);

The connection code needs to look like this:

dns lookup
while IP addresses left to try
{
advance to next address in dns results
if connect succeeds break
}
(Assignee)

Comment 9

11 years ago
Created attachment 295844 [details] [diff] [review]
Patch to retry after connect failure in SOCKS

Here's a trivial (but untested) patch to address this.
If you could test, that would be great :)
(Assignee)

Comment 10

11 years ago
Created attachment 295849 [details] [diff] [review]
Alternative patch for nsSOCKSIOLayer.cpp
(Assignee)

Comment 11

11 years ago
Jeremy, are you able to confirm if this patch (the 2nd one) resolves this issue for you?

Thanks,
David.

Comment 12

11 years ago
Moving to blocking - clearly bad regression
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1

Updated

11 years ago
Summary: turning on ipv6 on again on mac (Bug 408881) broke SOCKS proxy support → Re-enabling IPv6 on mac breaks SOCKS support for localhost
Assignee: nobody → david
Keywords: checkin-needed
Checking in netwerk/socket/base/nsSOCKSIOLayer.cpp;
/cvsroot/mozilla/netwerk/socket/base/nsSOCKSIOLayer.cpp,v  <--  nsSOCKSIOLayer.cpp
new revision: 1.19; previous revision: 1.18
done
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
(Reporter)

Comment 14

11 years ago
Sorry, I didn't get back to you sooner.

trunk 20080107_2221 WFM with localhost as proxy.

(In reply to comment #7)
> BTW, is this a test case or a real use case?  Using a SOCKS proxy on localhost
> seems like a fairly unlikely thing to want to do.

Yes.  2 examples:
* tunneling a cleartext proxy connection through stunnel/ssh
* using ssh's builtin SOCKS emulation to route browser connections through an ssh server.

My guess is most people using a proxy bound to loopback would end up specifying localhost in Firefox prefs unless told to do something different. (and for that matter existing tutorials/docs)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.