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

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Nov 22 08:27:43 UTC 2017


#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-------------------------------------------+-------------------------------
 Reporter:  gk                             |          Owner:  nickm
     Type:  defect                         |         Status:
                                           |  needs_information
 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:
Parent ID:                                 |         Points:  0.5
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------
Changes (by teor):

 * status:  needs_revision => needs_information


Comment:

 > The first bad commit is 93a8ed3b83b5f20768562ca2aff4eba7aca667d8.

 I'm not sure this is correct.

 Bridges didn't work at all between c21cfd28f4 (#17750) and 93a8ed3b83
 (#23347).
 So you might want to check if c21cfd28f4^ (63ceadb485) is a bad commit or
 not.
 If it is, your problem goes much further back in Tor, or it is in Tor
 Browser or Tor Launcher.

 Replying to [comment:7 gk]:
 > Replying to [comment:3 teor]:
 > > I think this branch fixes the issue after quitting the browser. It
 might also fix the stalled bootstrap or error, but I'm not sure. Can you
 re-test with this branch?
 >
 > Neither of those cases is fixed for me. I am still getting the error
 that Tor was unable to connect to an `obfs3` address even though I
 switched to `obfs4` during start-up. And after restarting I am stuck at
 > {{{
 > Nov 22 08:57:04.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 > Nov 22 08:57:04.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 > Nov 22 08:57:04.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 > Nov 22 08:57:04.000 [notice] Opening Socks listener on 127.0.0.1:9150
 > }}}

 This looks like a Tor Browser or Tor Launcher bug, not a Tor bug: when
 DisableNetwork is set, Tor is behaving as designed by not making any
 connections.

 Or, there aren't enough log entries here to diagnose why Tor Launcher has
 set DisableNetwork, and which component is at fault.

 > So, the only thing that is gone is
 > {{{
 > [notice] Ignoring directory request, since no bridge nodes are available
 yet.
 > }}}
 > I used d7833c9d27feed9e for testing.

 Excellent, then we've fixed one bug that was definitely in Tor.

 Let's open other tickets for the remainder?

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


More information about the tor-bugs mailing list