GitLab

In commit bf2a399fc0d90df76e091fa3259f7c1b8fb87781 we made all SocksPort to prefer IPv6 which means that any DNS resolution answer will pick IPv6, if exists, over IPv4.

For torsocks, this is a problem because by default it tries to resolve an IPv4. This can be fixed except when the libc call (ex: getaddrinfo()) is specifically requesting an IPv4 (hints.ai_family = AF_INET).

There is currently no way for torsocks to ask tor, via the SocksPort, a specific INET family and thus torsocks receives back the IPv6 and can't handle it because the application was expecting an IPv4.

So this example fails often as we have more and more Exits are able to resolve IPv6:

wget -4 some.url

And still many applications by default will request an IPv4 because they don't handle IPv6.

Bottom line is that torsocks use case is broken for when an application is specifically requesting an INET family...

As a reminder, torsocks can not pass the hostname directly in the SOCKS connection because it hijacks libc calls and thus flow can only be 1) DNS resolution, 2) connect() with an IP address.

I'm not sure what to do here... I think the ideal scenario would be to have a way for our "resolve" SOCKS extension to specify an address family value.

For instance, the F0 (RESOLVE command) would be "return whatever" and then we could extend to have RESOLVE4 and RESOLVE6..... HACK-ish but those extensions are already a hack so...

(That prefer IPv6 change went in 043)