Opened 5 months ago

Last modified 3 months ago

#30639 new defect

Tor tries to connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort set

Reported by: gk Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tbb-wants, network-team-roadmap-maybe, bootstrap, 041-deferred-20190719
Cc: teor, mcs, brade, catalyst Actual Points:
Parent ID: #29641 Points:
Reviewer: Sponsor:

Description

In #29641 we set ClientAutoIPv6ORPort 1 to help users in IPv6-only networks. However, that leads to bootstrap errors, presumably because Tor is trying to use IPv6 in IPv4-only networks. See e.g.:

https://blog.torproject.org/comment/281976#comment-281976
https://blog.torproject.org/comment/282102#comment-282102

I've seen this myself as well when bootstrapping on a Windows machine at least. Just hitting the "Reconfigure" option and choosing "Connect" again "solved this issue.

Child Tickets

Change History (15)

comment:1 Changed 5 months ago by gk

Component: - Select a componentCore Tor/Tor

comment:2 Changed 5 months ago by gk

Closed #30640 as duplicate.

comment:3 Changed 5 months ago by teor

This bug is caused by an interaction between tor and Tor Browser:

  1. Tor speculatively tries IPv4 and IPv6
  2. Some of those connections fail
  3. Tor Browser sets DisableNetwork on any failure

Here are some solutions that probably won't work:

  • we could try to auto-detect IPv4 or IPv6 addresses (#27492), but that's not reliable, because:
    • local addresses don't guarantee internet connectivity
    • some OSes and security configs don't allow tor to read local network information
  • we could downgrade the warning on the Tor side, but that might have unintended consequences for other applications that use tor
    • if fiddling with warning levels is our best option, we could defer the warning for 30? seconds, and cancel the pending warning if another tor connection succeeds

Here's a solution that would work, but we need to schedule it in tor's roadmap:

  • we could implement a proper "happy eyeballs" style connection design in tor, where we always choose an IPv4 and IPv6 address for every connection, try both, and use the first one that works

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

Here's a quick fix that restores the previous behaviour (and re-opens #29641):

  • revert the change that added ClientAutoIPv6ORPort to Tor Browser alpha

Let me know how you'd like to move forward, and what you need the network team to do.

comment:4 Changed 5 months ago by gk

Cc: mcs brade added

comment:5 Changed 5 months ago by catalyst

Milestone: Tor: unspecified

comment:6 Changed 5 months ago by gaba

Keywords: network-team-roadmap-maybe added

comment:7 Changed 5 months ago by mcs

Summary: Tor tries so connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort setTor tries to connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort set

comment:8 in reply to:  3 ; Changed 5 months ago by mcs

Replying to 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.

comment:9 Changed 5 months ago by nickm

Keywords: 041-should added
Milestone: Tor: unspecifiedTor: 0.4.1.x-final

So long as this is a user-facing issue, it seems like 041-should or -must to me. Putting it there until/unless we fix it, or decide differently.

comment:10 in reply to:  8 Changed 5 months ago by teor

Replying to mcs:

Replying to 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.

comment:11 Changed 5 months ago by catalyst

Cc: catalyst added
Keywords: bootstrap added

comment:12 Changed 5 months ago by catalyst

See #25713 for more about how DisableNetwork logs confuse users.

comment:13 Changed 5 months ago by gk

Parent ID: #29641

comment:14 Changed 3 months ago by nickm

Keywords: 041-deferred-20190719 added; 041-should removed

Add 041-deferred-20190719 tag to 041-should tickets I am deferring today.

comment:15 Changed 3 months ago by nickm

Milestone: Tor: 0.4.1.x-finalTor: unspecified
Note: See TracTickets for help on using tickets.