[tbb-bugs] #27351 [Applications/Tor Browser]: DisableNetwork is not unset if bootstrapping fails (was: Reloading TB's Tor instance disables network)

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Aug 30 09:34:42 UTC 2018


#27351: DisableNetwork is not unset if bootstrapping fails
--------------------------------------+--------------------------
 Reporter:  traumschule               |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by traumschule):

 I think the actual problem is that DisableNetwork does not get unset after
 Tor is (re)started if the bootstrapping fails and the user never gets to
 know why. I considered closing this as "Not a bug" because of my own
 fault, if you agree, just do it, but maybe there's something to learn for
 the future.

 When I kill TB's Tor process this message pops up:
 > Tor unexpectedly exited. This might be due to a bug in Tor itself,
 another program on your system, or faulty hardware. Until you restart Tor,
 the Tor Browser will not able to reach any websites. If the problem
 persists, please send a copy of your Tor Log to the support team.
 > Restarting Tor will not close your browser tabs.

 It gives me the options "Ok" and "Restart Tor".

 It could also say "To Restart Tor later open the Network Settings via the
 onion menu." and offer the buttions "Restart Tor" "Keep Network turned
 off". Now a user knows, it was a deliberate decision, even when some other
 application killed tor without the user being aware of it.

 When I click "Restart Tor" in the Network Settings dialogue, Tor gets
 restarted and I see the bootstrap dialogue after clicking "OK".

 It is usually fine for most users except for those who edited torrc, so
 one could say "Their fault", they should know what they are doing. In my
 case I added another SocksPort. To solve this issue and possible future
 issues, the Tor Launcher would need to be smart enough to disable the
 SocksPort or other ports that could be set. I guess this is unfeasable.
 But why is Tor unable to bind to this port with "Adress in use", the
 former Tor process is not there anymore. At this point I realized that I
 was stupid enough to set it to 9050. I just reproduced it:

 {{{
 8/30/18, 08:38:19.800 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 8/30/18, 08:38:19.800 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 8/30/18, 08:38:19.800 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 8/30/18, 08:38:19.800 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 8/30/18, 08:38:19.810 [NOTICE] Bootstrapped 80%: Connecting to the Tor
 network
 8/30/18, 08:38:19.820 [NOTICE] Renaming old configuration file to
 "/home/user/src/tor/tor-
 browser8.0a10/Browser/TorBrowser/Data/Tor/torrc.orig.1"
 8/30/18, 08:38:19.820 [NOTICE] Bootstrapped 85%: Finishing handshake with
 first hop
 8/30/18, 08:38:20.830 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 8/30/18, 08:38:26.393 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 8/30/18, 08:38:26.393 [NOTICE] Bootstrapped 100%: Done
 8/30/18, 08:45:32.980 [NOTICE] New control connection opened from
 127.0.0.1.
 8/30/18, 08:46:21.427 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 8/30/18, 08:46:21.692 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 8/30/18, 08:46:21.692 [NOTICE] Bootstrapped 100%: Done
 8/30/18, 08:46:31.995 [NOTICE] New control connection opened from
 127.0.0.1.
 }}}
 Nyx connected two times, the first time i killed the tor process to set
 the nonsensical already attached to SocksPort and the interface hangs with
 the "Starting" message. But the important message that it cannot attach to
 the requested port is not even logged, because DisableNetwork only gets
 unset when the bootstrap succeeded. The important question that should
 appear in the UI if starting hangs for a while:

 comment:3:ticket:24627:
 > With DisableNetwork set, the .onion you tried to reach will inevitably
 fail because Tor just won't do any actions on the network.
 > Did you do anything special to your "tor" process or torrc file that
 would set that value? Were you using Tor Browser here? Maybe your computer
 didn't had connectivity anymore?

 Also the Copy Tor Log To Clipboard method is not the best option in my
 eyes. What is the reasoning? If the goal is to hide technical stuff, the
 ui should be clever to show the relevant error, maybe the last warning. I
 remember Vidalia showed the log in a tab, it could be another button or
 tab. Not every user is comfortable to paste the whole log into a pastebin
 or text editor, but it is more common (for me) to pick selected message to
 paste them into IRC or mails. Also repeating messages like DisableNetwork
 is set could be scrubbed like nyx does. (i stop here, fantasy is fast,
 implementation hard)

 How should DisableNetwork be unset? After the bootstrap succeeded. The
 control process checks for this, but also the UI could have a button
 "Enable Network" and show the answer if it fails.

 comment:4:ticket:25713
 > I think Tor Browser sets DisableNetwork whenever the configuration
 dialog is up, which can also happen if bootstrap failed for some reason.

 {{{
 src/chrome/content/network-settings.js:

 function useSettings()
 1851:  settings[kTorConfKeyDisableNetwork] = false;

 stopTorBootstrap()
 1890:  const kErrorPrefix = "Setting DisableNetwork=1 failed: ";

 src/components/tl-process.js:

 319:  TorStartAndControlTor: function(aForceDisableNetwork)
 328:    this._startTor(aForceDisableNetwork);
 331:    this._controlTor(isRunningTor, aForceDisableNetwork);

   _startTor: function(aForceDisableNetwork)
 360:  _startTor: function(aForceDisableNetwork)
 490:      if (aForceDisableNetwork ||
 TorLauncherUtil.shouldShowNetworkSettings ||
       if (aForceDisableNetwork ||
 TorLauncherUtil.shouldShowNetworkSettings ||
           defaultBridgeType)
       {
 493:        args.push("DisableNetwork");
         args.push("1");
       }

   _configureDefaultBridges: function()
   {
     var settings = {};
     var bridgeArray = TorLauncherUtil.defaultBridges;
     var useBridges =  (bridgeArray &&  (bridgeArray.length > 0));
     settings["UseBridges"] = useBridges;
     settings["Bridge"] = bridgeArray;
     var errObj = {};
     var didSucceed = this.mProtocolSvc.TorSetConfWithReply(settings,
 errObj);

     // If the network settings wizard was not opened at startup, enable
 the
     // network so that bootstrapping will proceed with the default
 bridges.
     if (!TorLauncherUtil.shouldShowNetworkSettings)
     {
       settings = {};
 697:      settings["DisableNetwork"] = false;
       if (!this.mProtocolSvc.TorSetConfWithReply(settings,
                                                  (didSucceed) ? errObj :
 null))
       {
         didSucceed = false;
       }
     }
 }}}

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


More information about the tbb-bugs mailing list