bridges fail on Tor 0.3.4.1-alpha and later
When I run the chutney bridges-min and bridges+ipv6-min tests on my mac, they fail on every release from 0.3.4.1-alpha through to master (837f11a532). But they succeed on maint-0.3.3, maint-0.3.2, and maint-0.2.9.
Activity
changed milestone to %Tor: 0.3.4.x-final
To run chutney on master, you'll need the fix in #27067 (moved).
Trac:
27080_bisect.log-
Somebody should find out whether this affects bridges and/or bridge clients on the real network, or whether it is a chutney-only bug. That will determine whether it is super-high-priority or just regular high-priority.
I've reproduced this on a Fedora system, and tried to bisect. My result was that the first bad commit is ed89bb32535fbf354b406a36f3176380a4e226bf" "Specialize the periodic events on a per-role basis." So I would guess that this does affect real users. I've attached my "git bisect" log, in case I messed up somewhere.
Trac:
Severity: Normal to Major
Priority: Medium to High
Cc: N/A to dgoulet Thanks!
I had a quick look through that commit. The code changes shouldn't change tor's behaviour. I wonder if the bug is in this commit, but the behaviour actually starts happening in the commit after it (a4fcdc5dec).
In a4fcdc5dec, the following roles seem inconsistent:
+ CALLBACK(retry_dns, PERIODIC_EVENT_ROLE_ROUTER), + CALLBACK(check_dns_honesty, PERIODIC_EVENT_ROLE_RELAY),It's probably unrelated, but I don't think clients write stats:
+ CALLBACK(write_stats_file, PERIODIC_EVENT_ROLE_ALL),(Do onion services write stats?)
I'll do some testing over the next 2 days, and try to work out what's happening.
Trac:
Status: new to needs_information
FWIW the Tails automated integration tests that exercise regular bridges and obfs4 pass just fine on an ISO that has tor installed from the deb.tpo tor-nightly-0.3.4.x-stretch APT suite. We use a rather old version of Chutney and not the real network. The host (that runs Chutney) has tor 0.2.9.15-1.
Replying to intrigeri:
FWIW the Tails automated integration tests that exercise regular bridges and obfs4 pass just fine on an ISO that has tor installed from the deb.tpo tor-nightly-0.3.4.x-stretch APT suite. We use a rather old version of Chutney and not the real network. The host (that runs Chutney) has tor 0.2.9.15-1.
I'm not sure which Tor versions pass your bridge tests. Are you running Tor 0.3.4 or Tor 0.2.9 in chutney?
-
Replying to teor:
Replying to intrigeri:
FWIW the Tails automated integration tests that exercise regular bridges and obfs4 pass just fine on an ISO that has tor installed from the deb.tpo tor-nightly-0.3.4.x-stretch APT suite. We use a rather old version of Chutney and not the real network. The host (that runs Chutney) has tor 0.2.9.15-1.
I'm not sure which Tor versions pass your bridge tests. Are you running Tor 0.3.4 or Tor 0.2.9 in chutney?
The client (in the Tails system under test, that's running in a VM and exercises bridges and obfs4 usage) runs tor 0.3.4.6-rc-dev-20180815T162312Z-1~d90.stretch+1. The host, that runs the Chutney network, has tor 0.2.9.15-1.
Trac:
git_bisect.log#27080 (moved) bisect log using chutney-git-bisect.sh
Trac:
chutney-git-bisect.shI get the following result from git bisect:
1f739e9b06974566685c662c3526384efd68ed32 is the first bad commit commit 1f739e9b06974566685c662c3526384efd68ed32 Author: David Goulet <dgoulet@torproject.org> Date: Wed May 2 13:42:24 2018 -0400 dirauth: Move authdir_mode_v3() to module This function must return false if the module is not compiled in. In order to do that, we move the authdir_mode_v3() function out of router.c and into the dirauth module new header file named mode.h. It is always returning false if we don't have the module. Closes #25990 Signed-off-by: David Goulet <dgoulet@torproject.org>I used the attached script to generate the attached log.
Hmm, using a slightly different method I get:
488e2b00bf881b97bcc8e4bbe304845ff1d79a03 is the first bad commit commit 488e2b00bf881b97bcc8e4bbe304845ff1d79a03 Author: Nick Mathewson <nickm@torproject.org> Date: Tue Apr 17 11:39:16 2018 -0400 Refactor the "block the connection on bandwidth" logic Right now, this patch just introduces and exposes some new functions. Later, these functions will get a little more complexity.Time to look at the tor logs, I think.
-
I found one issue, which might or might not be a complete explanation here. This is from a client in the bridges-min network:
Aug 20 13:35:57.787 [notice] No Tor server allows exit to 127.0.0.1:4747. Rejecting.Looking at the cached-microdescs in the authority's directory, I saw that there is one with a correct policy line
p accept 1-65535-- corresponding to the network's exit, 002r. But the client did not have that microdescriptor cached: it had an older one one.Digging deeper, it appears that the client is receiving new conensuses, but it is not re-launching microdescriptor downloads fast enough. The router_have_minimum_dir_info() function is returning 1, so directory_info_has_arrived() is not launching any new descriptor downloads here.