Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

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

#22266: fix the jump-to-80% issue
------------------------------------+------------------------------------
 Reporter:  catalyst                |          Owner:  (none)
     Type:  defect                  |         Status:  needs_information
 Priority:  High                    |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor            |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:  usability, ux, ux-team  |  Actual Points:
Parent ID:                          |         Points:
 Reviewer:                          |        Sponsor:
------------------------------------+------------------------------------
Changes (by mcs):

 * status:  new => needs_information


Comment:

 Although the Tor Launcher fix in #23240 has been merged and seems to work,
 as Kathy and I are working on the revised Tor Launcher UI we have
 discovered that the approach used in our fix for #23240 no longer works.
 Specifically, after implementing #23262 (integrated progress bar), we see
 that a tor that has cached directory information (80% start) returns
 `PROGRESS=0` in response to the `GETINFO status/bootstrap-phase` command
 that Tor Launcher sends. This is surprising; Kathy and I think the right
 answer is `PROGRESS=80`. The problem with receiving zero is that our
 strategy for #23240 was to keep the progress bar hidden until we queried
 tor to find out the current bootstrap progress value.

 Tor Launcher starts tor with DisableNetwork=1 on the command line, and
 here is the sequence of control port commands that is issued:
 {{{
 SETCONF UseBridges Bridge
 SETCONF Socks4Proxy Socks5Proxy Socks5ProxyUsername Socks5ProxyPassword
 HTTPSProxy HTTPSProxyAuthenticator
 SETCONF ReachableAddresses
 SETCONF DisableNetwork=0
 SAVECONF
 GETINFO status/bootstrap-phase
 }}}

 It is that last command that returns `PROGRESS=0`.

 Can someone on the networking team confirm that this is occurring due to
 the internal architecture of tor? E.g., when `DisableNetwork=0` is
 received when networking is disabled, the process of enabling the
 networking code must be asynchronous (which leads to the confusing
 `GETINFO status/bootstrap-phase` response). That would explain problems
 like #15715 as well (and we do see what to us are spurious "Disable
 Network is set" NOTICE message in our testing because the commands above
 are immediately followed by some `GETCONF` commands).

 With Tor Launcher's current, separate progress window things work okay
 because there is enough delay between the `SETCONF DisableNetwork=0` and
 the `GETINFO status/bootstrap-phase` commands that tor returns
 `PROGRESS=80`.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22266#comment:11>
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