Make sure no conntrack modules are loaded (or more precisely: connection tracking is not active for the path to 127.192.0.0/10), otherwise curl will succeed! Use the IP address reported by drill.
# curl 127.192.A.B
Tor will report:
[warn] getsockopt() failed: No such file or directory
[warn] Fetching original destination failed. Closing.

Call curl again but this time with loaded conntrack modules.
# modprobe nf_conntrack_ipv4
# curl 127.192.A.B
It should succeed now.

Looking at the code it seems that getsockopt() is called. The patch activates a code path where getsockname() is called instead which seems to make it work even if no connection tracking is active. Maybe the author of that code can shed more light into that?

It appears to me that TPROXYing only works for me when connection tracking is active. When I apply the patch TPROXYing works for me no matter if conntection tracking is active or not.

...
Looking at the code it seems that getsockopt() is called. The patch activates a code path where getsockname() is called instead which seems to make it work even if no connection tracking is active. Maybe the author of that code can shed more light into that?

I think the behaviour you describe is what we want.

I re-wrote the code to make it behave consistently and improve how it was structured back in early 2016.

I don't know enough about transparent proxying to say anything else with any confidence.

I've been using the patched version (0001-trans_tproxy.patch) with a TPROXY iptables setup since I commented here and so far it's been working as expected for me.

The only real documentation about the TPROXY feature I found is from the kernel documentation (Documentation/networking/tproxy.txt). Unfortunately it does not say anything about getsockname() or getsockopt(SO_ORIGINAL_DST).

It seems that the TPROXY kernel feature enables transparent proxy capabilities without the need to DNAT (what else would be it's purpose then?). The above experiment backs this up because TPROXYing works without conntrack kernel modules loaded (conntracking is required for NAT). This only works with the above patch applied which utilizes getsockname() instead of getsockopt(SO_ORIGINAL_DST). Therefore it seems that getsockname() is the correct way.

Okay, sounds good. I've put your patch in a new branch bug18100_029 in my public repository, along with a commit message and a changes file. I'm merging it into master now. If nothing goes wrong (and I don't expect it will) we can backport to 0.2.9 and 0.3.0. Thanks!