411119 - Re-enabling IPv6 on mac breaks SOCKS support for localhost

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Jeremy Baron]

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)

Comment 1

[Jeremy Baron]

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

[Lorenzo Colitti]

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 :)

Comment 3

[Jeremy Baron]

(In reply to comment #2)
Yup, that seems to be it.  I guess this is really just "SOCKS chokes on IPv6 proxy server".

Comment 4

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

well does your socks server listen on ::1? Try:

netstat -ln | grep 8080

What does that show?

Comment 5

[Lorenzo Colitti]

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.

Comment 6

[David Luyer]

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.

Comment 7

[David Luyer]

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

[Lorenzo Colitti]

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
}

Comment 9

[David Luyer]

Attachment: 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 :)

Comment 10

[David Luyer]

Attachment: Alternative patch for nsSOCKSIOLayer.cpp

Comment 11

[David Luyer]

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

Thanks,
David.

Comment 12

[Mike Schroepfer]

Moving to blocking - clearly bad regression

Comment 13

[Reed Loden [:reed]]

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

Comment 14

[Jeremy Baron]

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)