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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:
                                                 |  0.4.1.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-wants, network-team-roadmap-     |  Actual Points:
  maybe 041-should                               |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:8 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.

 These numbers do not provide "a good balance". Since our fallback and
 bootstrap changes in Tor 0.2.8, Tor only makes about 7 connections in the
 first 30 seconds. So a safer balance would be the first 5 or 6 problems in
 the "connecting" phase. And with bridges, it would be the first (N-1)
 problems, where N is the number of bridges.

 And then there seem to be log messages which don't go through the
 recommendation filter,

 I think Tor needs to be much smarter here, if Tor Browser is relying on
 this behaviour.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs