[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:
Parent ID:                                 |         Points:  0.5
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------
Changes (by gk):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:8 teor]:
 >
 > > 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).

 You are mistaken here. The immediate parent of
 93a8ed3b83b5f20768562ca2aff4eba7aca667d8, which is
 6370fb77c586e9ad68c7d1ecb95be36137cb9067, is working perfectly fine: I can
 change the PT during bootstrap and even after restart the new PT is being
 used without any complaint. Exactly like the current behavior in 0.3.1.8
 is.

 > So you might want to check if the commit before 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.

 I am not convinced yet given that all things equal only
 93a8ed3b83b5f20768562ca2aff4eba7aca667d8 is breaking things for us. But
 let's assume for a minute that this is indeed the case then it would not
 explain why I still get the error when switching the PT during start-up in
 the first place.

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