Opened 10 months ago

Closed 2 months ago

#28140 closed defect (fixed)

Our circuit died due to an invalid selected path if switching to plugabble transports

Reported by: gk Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.3.2.7-rc
Severity: Normal Keywords: tor-path, regression, postfreeze-ok, 040-deferred-20190220
Cc: teor Actual Points:
Parent ID: #29875 Points:
Reviewer: Sponsor:

Description

On the blog we got a report about a Tor notice:

Tor NOTICE: Our circuit 0 (id: 570) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug.

(see: https://blog.torproject.org/comment/278164#comment-278164)

It turns out I can reproduce this quite often (but not always) if I switch to pluggable transports (e.g. the built-in obfs4 bridges) in Tor Browser while a page is still loading. Then I get log output like

Oct 22 09:41:00.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Oct 22 09:41:00.000 [notice] Our circuit 0 (id: 40) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug.
Oct 22 09:41:00.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Oct 22 09:41:00.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Oct 22 09:41:00.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.

(Note, I have no clue why the timestamp is always the same in this snippet but it seems this warning is emitted on a second basis and not stopping)

This makes Tor Browser essentially unusable until one changes settings again or restarts.

Child Tickets

Attachments (1)

28410_obfs4_obfs3.log.gz (57.8 KB) - added by gk 10 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 10 months ago by gk

I attached an info level log. This happened while I was on a big news site and first switching to the built-in obfs4 bridges (which worked) and then to obfs3 (which resulted in the the bug).

Changed 10 months ago by gk

Attachment: 28410_obfs4_obfs3.log.gz added

comment:2 Changed 10 months ago by nickm

Milestone: Tor: 0.3.5.x-final
Priority: MediumHigh

comment:3 Changed 10 months ago by gk

Cc: teor added

Okay, I am not sure where the "Circuit died due to an invalid selected path is coming from" (mightbe an additional bug) but the repeated "Failed to find node for hop #1 of our path. Discarding this circuit." and Tor essentially not working anymore afterwards is coming from git-690f646bf8a5de9b which made it into 0.3.2.7-rc.

The case to repro is:

1) Open a big news page in Tor Browser
2) Select obfs4 as PT to use a built-in bridge
3) Reload if necessary
4) Switch to obfs3
5) Reload if necessary

Let me know if you need more info.

comment:4 Changed 10 months ago by teor

Keywords: tor-path regression added
Parent ID: #25885
Version: Tor: 0.3.2.7-rc

I think that our path selection changes in #25885 will fix this issue. If they don't, they will provide better diagnostics.

comment:5 Changed 10 months ago by nickm

Milestone: Tor: 0.3.5.x-finalTor: 0.4.0.x-final
Parent ID: #25885
Status: newneeds_information

Unparenting this; putting it in needs_information to see whether it is fixed in 0.4.0, and if not, what the diagnostic says.

comment:6 in reply to:  description Changed 10 months ago by essentially

Replying to gk:

This makes Tor Browser essentially unusable until one changes settings again or restarts.

Unfortunately, this breaks the most common browsing experience (plain tor w/o bridges, WiFi network).
Neither changing settings to obfs4, nor switching back can help.
Killing tor process manually when obfs4proxy process is already running leads to tor process is unable to boot and exits immediately (config is default, switched from obfs4). Killing obfs4proxy process helps, but tor launcher got stuck at 80% for about a minute (no CPU or network activity), so it's hard to realize it's booting.
After all, the circuit display disappeared after the tor restart :(

comment:7 Changed 7 months ago by nickm

Keywords: postfreeze-ok added

Mark some tickets as postfreeze-ok, to indicate that I think they are okay to accept in 0.4.0 post-freeze. Does not indicate that they are all necessary to do postfreeze.

comment:8 Changed 6 months ago by nickm

Keywords: 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

comment:9 Changed 2 months ago by teor

Parent ID: #29875
Resolution: fixed
Status: needs_informationclosed

We think this is fixed by #29875 in Tor 0.4.1.2-alpha and later. Once the fix has been tested in a few alphas, we will backport it to 0.3.5 and 0.4.0.

Note: See TracTickets for help on using tickets.