Re: [tor-bugs] #29201 [Core Tor/Tor]: Tor bootstrap hangs when offline

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#29201: Tor bootstrap hangs when offline
-----------------------------------+-----------------------------------
 Reporter:  atagar                 |          Owner:  (none)
     Type:  defect                 |         Status:  needs_information
 Priority:  Medium                 |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor           |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:  040-deferred-20190220  |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+-----------------------------------

Comment (by teor):

 Replying to [comment:4 atagar]:
 > In this particular case I do not mind the behavior change. Stem's tests
 already intend to run when we're 0% bootstrapped so I need to investigate
 this more on my side...
 >
 > https://gitweb.torproject.org/stem.git/tree/test/runner.py#n629
 > https://gitweb.torproject.org/stem.git/tree/stem/process.py#n170
 >
 > Stepping back, maybe we should rethink bootstrapping more fundamentally?
 In particular...
 >
 > 1. Bootstrap behavior is undocumented. Traditionally this has been fine
 because it never changed.

 Bootstrap has been documented in the control spec since before Tor 0.2.6:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n3773

 The CLIENT_STATUS events remain the same:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2481

 There is also new bootstrap documentation for 0.4.0 and later:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n3496

 >    Stem and Txtorcon

 and now Chutney, see #22132

 >    use bootstrapping to determine "Is my tor process ready to do X?"
 where X are things like "make a circuit" or "run a hidden service". We
 don't care about the bootstrap percentage (see below), but we use their
 implication that tor has become ready to do things.
 >
 >    Our usage is causing you friction. We should use another mechanism or
 formalize this by documenting tor's bootstrapping behavior including what
 the various percentages (or messages) mean.

 If the existing CLIENT_STATUS event or bootstrap tags don't do what you
 need, or the documentation is incomplete, let's open separate tickets for
 each issue.

 > 2. If we're going to rethink bootstrapping maybe we should go further?
 Why do we even present bootstrapping as percentages? Does this make sense?
 >
 >    Said another way, if "tor is 13% boostrapped" what does that mean? It
 isn't a time estimate (we're not saying that we're 13% done). It's also
 not saying that tor is capable of 13% of its capabilities.
 >
 >    I suspect bootstrap percentages might be a holdover from Vidalia's
 progress bar, which from a user perspective always stunk (descriptor
 downloads usually dominate bootstrapping so the bar jumped to ~55%, hangs
 for a minute, then jumps to 100%).
 >
 >    Obligatory video: https://www.youtube.com/watch?v=1V2SHW6Qx_E
 >
 > Just spitballing, but how about the following?
 >
 > 1. Drop the bootstrap percentage.

 The bootstrap percentage is used by Tor Browser.

 > 2. Define bootstrap logging as purely informational (ie. controllers
 like Stem should not use it).

 Controllers should use CLIENT_STATUS events or the bootstrap tags, as
 documented:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2500

 > 3. Add GETINFO commands that answer any "Is tor ready to do X?"
 inquiries.

 I think the CLIENT_STATUS events do what you're asking for?
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2481

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29201#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs