[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] random onion non-reachability



On Fri, Jan 5, 2018 at 8:36 AM, Andreas Krey <a.krey@xxxxxx> wrote:

> Hi everyone,
>
> I keep noticing a phenomenon regarding onion sites reachability.
> Every now and then some onion site becomes unreachable from
> a given tor browser instance while continuing to be reachable
> from others. After a few days it becomes reachable again from
> that instance as well. Happens with different onion services
> and different browser instances (it's not always the same
> service or instance involved).
>
> Any idea what causes this? Random outage of rendevous points?
>
> (The onion sites I observe this with are raspberries,
> partially behind a NAT, under my control.)
>
>
I've noticed similar with a group of services I've been experimenting with.
Each of those services is configured in Single-Hop mode

I initially assumed it related to this -
https://trac.torproject.org/projects/tor/ticket/21969 - but haven't really
had much chance to dig into it much further as I've been busy with other
stuff.

It's happened fairly frequently, but Tor's loglines aren't always the same.
Because I use a dedicated routing system to decide which address to send
you too, in the meantime I've just adjusted the routing status checks to
always force a new circuit (to increase the chances of detecting the
issue).

In all cases, restarting Tor on the Hidden Service helps.

The various loglines I've seen are:

Case1:

Tor[3546]: I learned some more directory information, but not enough
to build a circuit: We're missing descriptors for some of our primary
entry guard
s


Case2:

 Tor[5944]: Received http status code 404 ("Consensus is too old")
from server '149.56.157.119:9001' while fetching consensus directory


Case3:

Tor[15520]: Giving up launching first hop of circuit to rendezvous
point [scrubbed] for service


I did also dump Tor into debug mode and repro the issue, but I won't paste
the output here as nothing stands out, and I can't be bothered to sit and
scrub stuff out of it unless it's likely to be helpful.

I've not actually noticed any instances of this in the last week or so, but
it may be that I've simply missed them (now that recovery is somewhat
automated). It might also be, though, that it coincided with a period where
a whole bunch of people were updating their relays  - I first started
seeing the issue after the update enabling next-gen hidden service names
(though, for reference, the affected services are all using 'legacy' names).

As far as I've been able to make out, It does appear to relate to
establishing new circuits - existing circuits continue to work just fine
(which meant all my routing status checks were initially passing, natch),
but if you try to create a new connection (forcing the HS to build a new
circuit out to the RP) it fails. But seemingly not for all attempts
(perhaps some get lucky and we're able to use partially cached information?)

Ben




> - Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds <torvalds@*.org>
> Date: Fri, 22 Jan 2010 07:29:21 -0800
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>



-- 
Ben Tasker
https://www.bentasker.co.uk
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk