[tor-dev] Accessing hidden services with TAP or ntor
grarpamp at gmail.com
Fri Mar 7 22:56:45 UTC 2014
On Thu, Feb 20, 2014 at 9:01 PM, Qingping Hou <dave2008713 at gmail.com> wrote:
> On Thu 20 Feb 2014 05:41:53 PM EST, grarpamp wrote:
>> Would be nice to be able to fetch and print out the HS descriptor from the
>> controller. I posted/ticketed a rough proposed command operation spec
>> for that maybe 6mo ago that we had some mutual review/interest/code
>> on this list. Don't know it's current status... Qingping?
> Printing out the whole descriptor in controller will be something nice
> to have :)
> However, I think to trouble shoot this issue, current events in
> controller is probably enough. You can at least get following
> * can we get a descriptor off the hsdirs
> * if not, likely something bad happened on hsdir
> * can we establish rendezvous circuit
> * if not, chosen RP suddenly disappeared from the network?
> * can we receive introduction ack
> * if not, try another introduction point
> * can RP join the rendezvous circuit
> * can we get any reply from the stream
> * if not, there is something wrong with HS
> This should be able to help us narrow the problem.
Yes events and other debugging would help find any protocol buggyness.
My goals were different... what are the HS metainfo, and is HS reachable/up?
>> - can we get a descriptor off the hsdirs, why/not, and print it out in full
>> - can we rendezvous, build and connect to the far end tor, why/not, and print
>> - can we get reply from whatever may be listening on HiddenServicePort
Clarifying the above...
The first info can only come from querying the controller.
The second should have read to just return a 0/1 and why for an
end2end circ build to HS.
The latter is just a userspace action, not a scope for any controller function.
I should try to write a query spec.
Yes, the 'why/not' parts of the hsdir and circuit queries could perhaps
be ideally supplied by your deeper event tracking.
It's easier to answer the goals when asking the controller
directly on sync demand, rather than async watching events
triggered externally by sending socks5 requests for onions.
> Is it very easy to reproduce this for any HS?
Any trouble I've seen with HS has felt like inconsistent
network issues, such as packet loss, or just server issues.
The deeper events or logging could rule out Tor there.
And the query goals I have could rule in a reproducible HS.
More information about the tor-dev