Opened 2 years ago

Last modified 18 months ago

#16934 accepted defect

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

Reported by: sponville Owned by: dgoulet
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 (5)

comment:1 Changed 2 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 23 months 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 23 months 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 18 months ago by dgoulet

Status: newaccepted

Accept a bunch of tickets for torsocks.

comment:5 Changed 18 months ago by dgoulet

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

Note: See TracTickets for help on using tickets.