Opened 2 years ago

Last modified 2 years ago

#27351 new defect

DisableNetwork is not unset if bootstrapping fails

Reported by: traumschule Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: s8-errors
Cc: mcs, brade, nickm, catalyst Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Reloading TB's Tor instance disables network and keeps it turned off because it fails to attach to the SocksPort.
One has to change the SocksPort, enable the network and change back the SocksPort with nyx:

>>> signal reload
250 OK

>>> getconf disablenetwork
250 DisableNetwork=1

>>> setconf disablenetwork=0
553 Unable to set option: Failed to bind one of the listener ports.

>>> setconf socksport=9152
250 OK

>>> setconf disablenetwork=0
250 OK

>>> setconf socksport=9150
250 OK

Child Tickets

Change History (5)

comment:1 Changed 2 years ago by gk

Cc: mcs brade added
Keywords: tbb removed

comment:2 Changed 2 years ago by mcs

Cc: nickm added

I don't think this is something that can easily be fixed inside Tor Browser. Tor Launcher configures the ControlPort and SocksPort via args that are used when starting the tor process. Does tor ignore command line args when it does a reload? I wonder if that is the intended behavior.... I am adding Nick so he can provide an opinion. I assume this bug is not urgent, so no rush.

comment:3 Changed 2 years ago by traumschule

looked into the future, opened two files and thinking about #25713 now

src/chrome/content/network-settings.js:93:const kTorConfKeyDisableNetwork = "DisableNetwork";                                                                                   
src/chrome/content/network-settings.js:1851:  settings[kTorConfKeyDisableNetwork] = false;                                                                                      
src/chrome/content/network-settings.js:1890:  const kErrorPrefix = "Setting DisableNetwork=1 failed: ";                                                                         
src/chrome/content/network-settings.js:1894:    settings["DisableNetwork"] = true;
src/components/tl-process.js:319:  TorStartAndControlTor: function(aForceDisableNetwork)                                                                                        
src/components/tl-process.js:328:    this._startTor(aForceDisableNetwork);
src/components/tl-process.js:331:    this._controlTor(isRunningTor, aForceDisableNetwork);                                                                                      
src/components/tl-process.js:360:  _startTor: function(aForceDisableNetwork)
src/components/tl-process.js:490:      if (aForceDisableNetwork || TorLauncherUtil.shouldShowNetworkSettings ||                                                                 
src/components/tl-process.js:493:        args.push("DisableNetwork");
src/components/tl-process.js:697:      settings["DisableNetwork"] = false;

comment:4 Changed 2 years ago by traumschule

Summary: Reloading TB's Tor instance disables networkDisableNetwork is not unset if bootstrapping fails

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 
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 
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 

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:


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.


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


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

1890:  const kErrorPrefix = "Setting DisableNetwork=1 failed: ";


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 ||
493:        args.push("DisableNetwork");

  _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;

comment:5 Changed 2 years ago by catalyst

Cc: catalyst added
Keywords: s8-errors added

I think we should only log about DisableNetwork being set once each time it gets set, instead of each time tor tries to open a connection somewhere. We should also log when it is unset, because right now it's not, and that can confound the interpretation of the log messages following the one that mentions DisableNetwork being set. I'm pretty sure Tor Launcher sets DisableNetwork=0 once the user clicks OK on the Tor network settings dialog.

Note: See TracTickets for help on using tickets.