[tor-onions] Onion self healing / republish

[George Kadianakis]

Péter Szilágyi <peterke at gmail.com> writes:

> Hey all,
>
> I'm sorry if this is something obvious, I've searched for a day and
> couldn't find satisfactory information. Feel free to point me to relevant
> resources if I missed them.
>
> So, I'd like to run Tor in a P2P setting on mobile phones (
> https://github.com/coronanet). In general, everything works as expected. My
> issues are with the fine grained behaviors of the Tor proxy wrt onion
> addresses and network connectivity.
>
> As long as I allow a stable internet connection to Tor, everything's fine.
> What I wanted to check is how Tor behaves if I start pulling the rug from
> underneath it in various states.
>
> I've tried keeping Tor offline (network disabled), publish an onion into
> the service and then enable networking afterwards (SETCONF DisableNetwork
> 0). This also seems to work, when Tor goes online it publishes the onion
> that was added offline and I can access it (at least sending a HEARTBEAT
> signal reports "1 v3 INTRODUCE2 cells and attempted to launch 1 rendezvous
> circuits"). So far so good.
>
> Now comes the more interesting test: while networking is enabled and
> seemingly everything works, I cut off network access at the router level
> (i.e. simulate a phone losing WiFi signal / turning off data). Similar to
> my previous test, I've created a new onion in this scenario too, then
> reenabled WiFI. Unfortunately, whilst my first onion comes back online, the
> second one is lost in some black hole. My guess is that Tor **thinks** it's
> online, fails to register it, then some internal state gets messed up.
>
> If I try to list the current onions (GETINFO onions/current), both appear.
> If I try to list some infos about them via `GETINFO hs/service/desc/id/`,
> both look the same, reporting their own crypto keys. However, only the
> first one response, the second never gets router, neither noticed by the
> local Tor instance.
>
> At this point I'd be perfectly happy is this weird scenario was "not meant
> to work by design", as long as Tor could explicitly tell me somehow that
> "sorry, onion X is dead, sort it out yourself". I'd be even happier if this
> worked though. Maybe this is a bug that was fixed in a later version? I'm
> on 0.3.5.10.
>

Greetings friend,

while I don't have The Solution for you I have a few questions that will
take us closer to it:

a) What is the purpose of your experiments? Are you trying to simulate a
   phone losing WiFi signal?  If yes, that seems like a fine test to do
   and something that Tor should handle gracefully (and if it doesn't we
   should fix it ASAP).

   In general, hosting onion services over mobile is a use case that
   we've had trouble in the past, and we've been constantly trying to
   increase its stability, by getting feedback and help from our friends
   at the Briar project (cc'ed Michael) and Guardian project (cc'ed
   Nathan).

b) Yes, do use the latest alpha tor instead of 0.3.5.10. There are
   various logs and general reachability enhancements that might not
   have been backported that far back.

   Ideally you would even use Tor with git master since we recently
   merged a branch that should provide further debugging log messages in
   cases like yours:  https://trac.torproject.org/projects/tor/ticket/33400

c) It would be really useful to see some *info* logs from your service
   if you manage to reproduce this bug with Tor master. My intuition is
   that the second service fails to upload its descriptor because of Tor
   being offline, and then never notices the network going up to try
   again. Feel free to either upload your logs on Tor's trac (in a new
   ticket) or either send it to me and David Goulet (dgoulet at torproject.org).

Good luck and looking forward to hear back from your experiments!

PS: You might want to register on the mailing list because I had to
    manually approve your post.