[tor-bugs] #30639 [Core Tor/Tor]: Tor tries to connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort set

[Tor Bug Tracker & Wiki]

#30639: Tor tries to connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort
set
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-wants, network-team-roadmap-     |  Actual Points:
  maybe                                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mcs):

 Replying to [comment:3 teor]:
 > ...
 > Here's a fix that Tor Browser should implement anyway:
 > * stop setting DisableNetwork on tor's first connection failure, because
 tor's next connection attempt might work

 This is an interesting ticket.

 Tor Launcher does not set `DisableNetwork=1` on tor's first connection
 failure; it is more accurate to say that Tor Launcher displays an error
 message along with a `Reconfigure` button after it receives a bootstrap
 status event that includes `RECOMMENDATION=warn`, and Tor Launcher also
 sets `DisableNetwork=1` at the same time.

 The problem that Kathy and I see with changing Tor Launcher to not set
 `DisableNetwork=1` when a "warn" level bootstrap event occurs is that in
 many situations that will cause user confusion. In fact, if I remember
 correctly, Tor Launcher used to behave that way. Our current assumption is
 that when a "warn" level bootstrap event occurs, the bootstrap process has
 failed and the user needs to intervene to fix it (e.g., they need to
 modify their Tor configuration to use a bridge or fix their system clock).
 In this case, that may not be true.

 We count on tor to help us by adhering to this idea from section 4.1.10 of
 the control spec:
  Currently Tor uses recommendation=ignore for the first nine bootstrap
 problem reports for a given phase, and then uses recommendation=warn for
 subsequent problems at that phase. Hopefully this is a good balance
 between tolerating occasional errors and reporting serious problems
 quickly.

 But maybe the above does not apply to some types of failures inside tor,
 e.g., "no route to host?" We need to figure out how to avoid interrupting
 tor's bootstrap process inside tor and in the Tor Launcher UI; otherwise,
 Tor Launcher will behave as if a "fatal" error occurred even though one
 did not.

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