Opened 4 years ago

Last modified 21 months ago

#15713 accepted defect

toggling DisableNetwork during bootstrap causes delay

Reported by: mcs Owned by: arma
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.6.6
Severity: Normal Keywords: tor-client, bootstrap, delay, sponsor8-maybe, tbb-needs
Cc: brade, mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

While testing a fix for #11879, Kathy and I noticed that if the bootstrap process is interrupted by setting DisableNetwork=1 via the control port, Tor waits about a minute after DisableNetwork is set back to 0 before continuing network activity. We observed this problem on a Mac OS 10.8.5 system. Possibly related tickets: #9229, #11069.

Once release candidates for Tor Browser 4.5 are available, this should be reproducible by following these steps:

  1. Start Tor Browser and click "Connect".
  2. Click "Open Settings" in the connection progress window to interrupt the bootstrap process.
  3. Click "Connect" again. Notice that there is a delay before the bootstrap makes more progress.

We are also able to reproduce it using Tor 0.2.6.6 and a manual (telnet) control port connection. Follow these steps (control port authentication is up to you):

  1. Remove all cached Tor data and start Tor like this:

./tor --defaults-torrc torrc-defaults -f torrc DisableNetwork 1

  1. Make a control port connection and issue this command:

SETCONF DisableNetwork=0

  1. Wait for bootstrapping to reach 25-50% and then do:

SETCONF DisableNetwork=1

  1. Re-enable network access:

SETCONF DisableNetwork=0 Notice that there is a delay before the bootstrap makes more progress.

We used the torrc-defaults file that ships with Tor Browser 4.5a5:

# If non-zero, try to write to disk less frequently than we would otherwise.
AvoidDiskWrites 1
# Where to send logging messages.  Format is minSeverity[-maxSeverity]
# (stderr|stdout|syslog|file FILENAME).
Log notice stdout
# Bind to this address to listen to connections from SOCKS-speaking
# applications.
SocksPort 9150
ControlPort 9151
CookieAuthentication 1
## fteproxy configuration
ClientTransportPlugin fte exec PluggableTransports/fteproxy.bin --managed

## obfs4proxy configuration
ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec PluggableTransports/obfs4proxy

## flash proxy configuration
#
# Change the second number here (9000) to the number of a port that can
# receive connections from the Internet (the port for which you
# configured port forwarding).
ClientTransportPlugin flashproxy exec PluggableTransports/flashproxy-client --register :0 :9000

## meek configuration
ClientTransportPlugin meek exec PluggableTransports/meek-client-torbrowser -- PluggableTransports/meek-client

Our torrc is also from Tor Browser and it just contains a few paths:

DataDirectory /Users/.../tb-11879.app/TorBrowser/Data/Tor
GeoIPFile /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip
GeoIPv6File /Users/.../tb-11879.app/TorBrowser/Data/Tor/geoip6

I will attach some log output.

Child Tickets

Attachments (1)

15713-log.txt (3.6 KB) - added by mcs 4 years ago.
Tor output

Download all attachments as: .zip

Change History (13)

Changed 4 years ago by mcs

Attachment: 15713-log.txt added

Tor output

comment:1 Changed 4 years ago by mcs

Keywords: tbb-wants added

See #15715 for a related ticket.

comment:2 Changed 4 years ago by teor

Milestone: Tor: 0.2.???

comment:3 Changed 3 years ago by arma

Severity: Normal
Status: newneeds_information

mcs: can you still reproduce this using Tor git master? I just tried to reproduce it (using the telnet approach) and everything works swimmingly for me.

comment:4 Changed 3 years ago by mcs

I cannot reproduce it using Tor v0.2.8.2-alpha (included with Tor Browser 6.0a5). So I think this ticket can be closed. Has work been done in tor to fix this ticket as well as #15713? Or is this a case of miscellaneous fixes and architectural changes leading to some problems disappearing?

comment:5 in reply to:  4 Changed 3 years ago by mcs

Replying to mcs:

I cannot reproduce it using Tor v0.2.8.2-alpha (included with Tor Browser 6.0a5). So I think this ticket can be closed. Has work been done in tor to fix this ticket as well as #15713? Or is this a case of miscellaneous fixes and architectural changes leading to some problems disappearing?

Oops. I meant to refer to #15715.

comment:6 Changed 3 years ago by arma

Keywords: TorCoreTeam201606 added
Owner: set to arma
Status: needs_informationaccepted

comment:7 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:8 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:9 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:10 Changed 2 years ago by nickm

Keywords: TorCoreTeam201606 removed

comment:11 Changed 2 years ago by nickm

Keywords: tor-client bootstrap delay sponsor8-maybe added

comment:12 Changed 21 months ago by gk

Keywords: tbb-needs added; tbb-wants removed

Let's just use tbb-needs and use priority there to indicate how urgent we'd like to have those tickets fixed.

Note: See TracTickets for help on using tickets.