Opened 5 years ago

Last modified 8 months ago

#16934 new defect

youtube-dl (recent), torsocks 2.1.0 and TBB5+ failure

Reported by: sponville Owned by:
Priority: Medium Milestone:
Component: Core Tor/Torsocks Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


ERROR torsocks[29369]: [socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:690)
ERROR: Unable to download webpage: <urlopen error [Errno -4] Non-recoverable failure in name resolution> (caused by URLError(gaierror(-4, 'Non-recoverable failure in name resolution'),))

The error changes over time. But it is mostly in this range. With a fresh restart the problem goes away, but it is back after some time blocking all requests.

Stopping any TBB5 running and starting TBB4.5.3 makes everything go smooth again.

Besides TBB, nothing changes in the configuration.

Child Tickets

Change History (8)

comment:1 Changed 5 years ago by nickm

Component: TorTorsocks
Owner: set to dgoulet

This could be a torsocks issue; that file (socks5.c) isn't part of Tor.

comment:2 Changed 5 years ago by cypherpunks

Severity: Normal

This started happening to me with system tor after I followed Tor Browser's lead and set SocksPort 9050 IPv6Traffic PreferIPv6 so I suspect it happens when hitting an exit that supports IPv6.

One possible workaround which I haven't tried yet is to configure another socksport without IPv6 and tell torsocks to use that instead.

comment:3 Changed 5 years ago by cypherpunks

This seems to be a design flaw in the "SOCKS5_CMD_RESOLVE" command. Specifically, it appears that the client sends such a command containing the hostname to be resolved, but has no way of specifying whether it expects an IPv4 address or an IPv6 address in response - and tor sends back whichever address type it feels like using.

Correct me if I'm wrong, but the "RESOLVE" command seems to be a Tor-specific thing, not a standard part of the SOCKS5 protocol. Wouldn't it be better to limit "RESOLVE" to returning IPv4 addresses (the only type that torsocks can currently understand, AFAICT), and add separate "RESOLVE_V6" or "RESOLVE_V4_OR_V6" commands for the benefit of future clients?

With that said, the other option that comes to mind is for torsocks to do away with real IP addresses altogether, and handle all DNS names by mapping them to fake addresses, the same way .onion names are currently handled. Apart from perhaps wanting to allocate more than a /24 worth of fake addresses for this purpose, is there any reason this wouldn't work?

As a practical matter, users might sometimes want to know the real IP address of the service they're connecting to, so maybe this would make sense as a torsocks configuration option. But I think for most applications, the real IP address shouldn't matter, and there may be good reasons for the application *not* to know it (e.g., CDNs that use a different address depending on your exit node, or inadvertent leaks in applications not designed with privacy in mind.)

As a quick fix, would it be adequate to simply replace 'if (utils_strcasecmpend(hostname, ".onion") == 0)' with 'if (1)' in torsocks.c?

comment:4 Changed 4 years ago by dgoulet

Status: newaccepted

Accept a bunch of tickets for torsocks.

comment:5 Changed 4 years ago by dgoulet

This is definitely a v6 issue. youtube-dl -4 works fine (forcing IPv4). I'll look into this.

comment:6 Changed 3 years ago by fuzzyTew

I'm having a comparable issue using MapAddress .exit hosts in torrc . I can't curl them with torsocks, because torsocks gives the 'Resolve destination buffer too small' error when a domain resolves to an ipv6 address, and tor defaults to creating ipv6 automap addresses.

torsocks should either be upgraded to support ipv6 domain resolution, or tor should default to NoPreferIPv6Automap for SocksPort entries, so that it will interoperate with torsocks when installed.

comment:7 Changed 16 months ago by gaba

Owner: dgoulet deleted
Status: acceptedassigned

Releasing some old tickets.

comment:8 Changed 8 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.