Re: [tor-bugs] #27351 [Applications/Tor Browser]: DisableNetwork is not unset if bootstrapping fails

[Tor Bug Tracker & Wiki]

#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:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:   => s8-errors


Comment:

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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