Going from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't work

Going from obfs4 to snowflake using the Tor Network Settings from the Torbutton doesn't work, i.e. nothing happens and no website can load, if I restart the browser then snowflake works perfectly

changed milestone to %Tor: 0.3.5.x-final

Trac:
Child Ticket(s): #28027 (moved), #28140 (moved), #24367 (moved)

added 035-backport 040-backport actualpoints::.5 component::core tor/tor dgoulet-merge milestone::Tor: 0.3.5.x-final network-team-roadmap-2019-Q1Q2 owner::nickm points::.5 priority::medium resolution::fixed reviewer::ahf severity::normal sponsor::19-must status::closed tbb-needs type::defect version::tor 0.3.2.7-rc labels

Yeah, here is what I get in my logs

Mar 25 12:59:36.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 25 12:59:36.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.
[03-25 12:59:36] TorLauncher DBUG: Event response: 650 WARN Failed to find node for hop #1 of our path. Discarding this circuit. 
[03-25 12:59:36] TorLauncher DBUG: Event response: 650 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. 
Mar 25 12:59:37.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
[03-25 12:59:37] TorLauncher DBUG: Event response: 650 WARN Failed to find node for hop #1 of our path. Discarding this circuit. 
Mar 25 12:59:38.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
[03-25 12:59:38] TorLauncher DBUG: Event response: 650 WARN Failed to find node for hop #1 of our path. Discarding this circuit. 
Mar 25 12:59:39.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.

and so on.

Many thanks Georg for the confirmation.

This is reminiscent of #12774 (moved) for meek; but in that case it's caused by a race between multiple copies of Firefox. There's no Firefox here, but maybe it's related to a deeper cause, which is that tor quickly starts multiple copies of the transport program when you change transports, then kills all but one of them. It could be interfering with rendezvous or something.

This looks like a core tor PT regression.

Trac:
Version: N/A to Tor: 0.4.0.1-alpha
Component: Obfuscation/Snowflake to Core Tor/Tor
Milestone: N/A to Tor: 0.4.0.x-final

GeKo, can you confirm this behavior on Tor 0.3.5 as well?

That is, we need to figure out if this is a regression in Tor 0.4.0, or a bug that's been here for longer.

Replying to arma:

GeKo, can you confirm this behavior on Tor 0.3.5 as well?

Yes.

That is, we need to figure out if this is a regression in Tor 0.4.0, or a bug that's been here for longer.

In fact, the last good release is 0.3.2.6-alpha. More precisely 690f646bf8a5de9b is the first bad revision, which tries to work around my #24367 (moved). I guess all that trouble speaks for fixing the latter once and for all (too). :)

Trac:
Version: Tor: 0.4.0.1-alpha to Tor: 0.3.2.7-rc
Cc: dcf, arlolra, cohosh to dcf, arlolra, cohosh, teor
Keywords: N/A deleted, tbb-wants added

I will try and fix #24367 (moved) and #29875 (moved). I also opened #29956 (moved) so we make tests for these kinds of bugs.

Trac:
Owner: N/A to teor
Status: new to assigned
Sponsor: N/A to Sponsor19
Keywords: tbb-wants deleted, 040-must, tbb-needs, 040-backport, 034-backport, 035-backport added

Trac:
Owner: teor to N/A
Milestone: Tor: 0.4.0.x-final to Tor: 0.4.1.x-final
Keywords: 040-must deleted, N/A added
Sponsor: Sponsor19 to Sponsor19-must

Trac:
Keywords: N/A deleted, 041-should added

Trac:
Keywords: N/A deleted, network-team-roadmap-2019-Q1Q2 added

Okay, here come the steps tor reproduce this bug on a Linux system:

1. Take a clean, new Tor Browser alpha.
2. Start it with ./start-tor-browser.desktop --debug on the command line, but don't connect directly. Rather, configure obfs4 to use one of the built-in bridges.
3. Continue bootstrap afterwards.
4. When the browser window shows up click on the onion button on the toolbar and select "Tor Network Settings...".
5. Change the the PT selected to use snowflake, click OK.
6. You should see the Failed to find node for hop #1 of our path messages right away.

Okay, this is indeed reproducible. The problem appears to be that we don't realize we are missing a descriptor for our bridge and need to fetch it -- possibly because router_dir_info_changed() isn't getting called.

I think the right solution may be to call router_dir_info_changed() when the list of bridges changes.

Trac:
Owner: N/A to nickm
Status: assigned to accepted

034 is EOL in 10 days; no backport for this.

Trac:
Keywords: 034-backport deleted, N/A added

That seems to be part of the right solution, but not sufficient. The failure mode has changed here.

Ah, there was a second problem: num_usable_bridges() was counting bridges that were not actually configured any more.

This branch WFM when merged into master: bug29875_035. 0.3.5 PR at https://github.com/torproject/tor/pull/1066 Here it is merged into master, with a practracker update: bug29875_master. master PR at https://github.com/torproject/tor/pull/1067

In my testing, I had to wait a couple of minutes after changing the configuration for snowflake to work; I don't know whether that's typical.

It is possible that this will fix some cases of #24367 (moved) as well.

Trac:
Actualpoints: N/A to .5
Status: accepted to needs_review

Trac:
Reviewer: N/A to ahf