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

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  nickm
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.2.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  regression, tor-bridge-client,       |  Actual Points:
  s8-errors                                      |
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8-can
-------------------------------------------------+-------------------------
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:  regression, tor-bridge-client => regression, tor-bridge-
     client, s8-errors
 * sponsor:   => Sponsor8-can


Comment:

 Replying to [comment:12 mcs]:
 > Tor Launcher issues a `SETCONF DisableNetwork=1` command via the control
 port in the following three cases:
 > 3. After a bootstrap error is reported by tor. The reason Tor Launcher
 does that is because it is about to switch its user interface back to
 configuration mode, and we do not want bootstrapping to proceed while the
 user is making adjustments. That only leads to confusion, especially when
 users switch from using a PT and not using one and vice-versa.

 I recently updated to 7.5a8 (with the new Tor Launcher UI on Linux).  I
 saw the following via control channel when I was doing a clock skew test
 (client 27.5 hours in the future):

 {{{
 650 STATUS_GENERAL WARN CLOCK_SKEW SKEW=99000 SOURCE=OR:131.188.40.189:443
 650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=40 TAG=loading_keys
 SUMMARY="Loading authority key certs" WARNING="Clock skew 99000 in NETINFO
 cell from OR" REASON=CLOCK_SKEW COUNT=3 RECOMMENDATION=warn
 HOSTID="F2044413DAC2E02E3D6BCF4735A19BCA1DE97281"
 HOSTADDR="131.188.40.189:443"
 650 ORCONN $F2044413DAC2E02E3D6BCF4735A19BCA1DE97281~gabelmoo CONNECTED
 ID=28
 650 STREAM 24 FAILED 0
 131.188.40.188.$EBE718E1A49EE229071702964F8DB1F318075FF8.exit:80
 REASON=HIBERNATING
 650 STREAM 26 FAILED 0
 131.188.40.189.$F2044413DAC2E02E3D6BCF4735A19BCA1DE97281.exit:443
 REASON=HIBERNATING
 650-CONF_CHANGED
 650-DisableNetwork=1
 650 OK
 }}}

 There were no other control port connections open besides my manual one
 and Tor Launcher, so I'm pretty sure that SETCONF came from Tor Launcher.
 For some reason Tor Launcher did not change back to the configuration
 screen after sending the SETCONF.  Maybe at least this symptom is a Tor
 Launcher bug?

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