From 7ce8d5513ba388259e4e251d49183ef0fe9c8fa8 Mon Sep 17 00:00:00 2001 From: David Goulet Date: Mon, 5 Feb 2018 10:52:17 -0500 Subject: [PATCH 1/3] Make circuit_log_ancient_one_hop_circuits() ignore established service rendezvous Services can keep rendezvous circuits for a while so don't log them if tor is a single onion service. Fixes #25116 Signed-off-by: David Goulet --- changes/bug25116 | 4 ++++ src/or/circuituse.c | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-) create mode 100644 changes/bug25116 diff --git a/changes/bug25116 b/changes/bug25116 new file mode 100644 index 0000000000..b3e73feeaa --- /dev/null +++ b/changes/bug25116 @@ -0,0 +1,4 @@ + o Minor bugfixes (hidden service, heartbeat): + - Don't log in the heartbeat any long term established one hop rendezvous + points if tor is a single onion service. Fixes bug 25116; bugfix on + 0.2.9.6-rc; diff --git a/src/or/circuituse.c b/src/or/circuituse.c index 84574cd5b9..96cd3cd7e8 100644 --- a/src/or/circuituse.c +++ b/src/or/circuituse.c @@ -808,10 +808,10 @@ circuit_log_ancient_one_hop_circuits(int age) if (circ->timestamp_created.tv_sec >= cutoff) continue; /* Single Onion Services deliberately make long term one-hop intro - * connections. We only ignore active intro point connections, if we take - * a long time establishing, that's worth logging. */ + * and rendezvous connections. Don't log the established ones. */ if (rend_service_allow_non_anonymous_connection(options) && - circ->purpose == CIRCUIT_PURPOSE_S_INTRO) + (circ->purpose == CIRCUIT_PURPOSE_S_INTRO || + circ->purpose == CIRCUIT_PURPOSE_S_REND_JOINED)) continue; /* Tor2web deliberately makes long term one-hop rend connections, * particularly when Tor2webRendezvousPoints is used. We only ignore From fe3dfe7e38b4ad0c11ff05b7dbd0a9b1d7efc4a8 Mon Sep 17 00:00:00 2001 From: David Goulet Date: Wed, 7 Feb 2018 10:23:24 -0500 Subject: [PATCH 2/3] test: Bump to 10 msec gap in the monotonic test On slow system, 1 msec between one read and the other was too tight. For instance, it failed on armel with a 4msec gap: https://buildd.debian.org/status/package.php?p=tor&suite=experimental Increase to 10 msec for now to address slow system. It is important that we keep this OP_LE test in so we make sure the msec/usec/nsec read aren't desynchronized by huge gaps. We'll adjust again if we ever encounter a system that goes slower than 10 msec between calls. Fixes #25113 Signed-off-by: David Goulet --- changes/bug25113 | 5 +++++ src/test/test_util.c | 8 ++++---- 2 files changed, 9 insertions(+), 4 deletions(-) create mode 100644 changes/bug25113 diff --git a/changes/bug25113 b/changes/bug25113 new file mode 100644 index 0000000000..4a020b784d --- /dev/null +++ b/changes/bug25113 @@ -0,0 +1,5 @@ + o Minor bugfixes (unit test, monotonic time): + - Bump a gap of 1msec to 10msec used in the monotonic time test that makes + sure the nsec/usec/msec time read are synchronized. This change was + needed to accommodate slow system like armel or when the clock_gettime() + is not a VDSO on the running kernel. Fixes bug 25113; bugfix on 0.2.9.1. diff --git a/src/test/test_util.c b/src/test/test_util.c index 0b707caeeb..dd122b250d 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -5541,10 +5541,10 @@ test_util_monotonic_time(void *arg) tt_u64_op(usec1, OP_GE, nsec1 / 1000); tt_u64_op(msecc1, OP_GE, nsecc1 / 1000000); tt_u64_op(usecc1, OP_GE, nsecc1 / 1000); - tt_u64_op(msec1, OP_LE, nsec1 / 1000000 + 1); - tt_u64_op(usec1, OP_LE, nsec1 / 1000 + 1000); - tt_u64_op(msecc1, OP_LE, nsecc1 / 1000000 + 1); - tt_u64_op(usecc1, OP_LE, nsecc1 / 1000 + 1000); + tt_u64_op(msec1, OP_LE, nsec1 / 1000000 + 10); + tt_u64_op(usec1, OP_LE, nsec1 / 1000 + 10000); + tt_u64_op(msecc1, OP_LE, nsecc1 / 1000000 + 10); + tt_u64_op(usecc1, OP_LE, nsecc1 / 1000 + 10000); done: ; From 33a80921a2e7bbf128c27a1a0c4903a9a322708a Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 26 Mar 2018 09:17:50 -0400 Subject: [PATCH 3/3] When extending a circuit's path length, clear onehop_tunnel. There was a nonfatal assertion in pathbias_should_count that would trigger if onehop_tunnel was set, but the desired_path_length was greater than 1. This patch fixes that. Fixes bug 24903; bugfix on 0.2.5.2-alpha. --- changes/bug24903 | 5 +++++ src/or/control.c | 3 +++ 2 files changed, 8 insertions(+) create mode 100644 changes/bug24903 diff --git a/changes/bug24903 b/changes/bug24903 new file mode 100644 index 0000000000..01c9b53f23 --- /dev/null +++ b/changes/bug24903 @@ -0,0 +1,5 @@ + o Minor bugfixes (controller, reliability): + - Avoid a (nonfatal) assertion failure when extending a one-hop circuit + from the controller to become a multihop circuit. Fixes bug 24903; + bugfix on 0.2.5.2-alpha. + diff --git a/src/or/control.c b/src/or/control.c index 03d9fcee2a..ff7f2e8b85 100644 --- a/src/or/control.c +++ b/src/or/control.c @@ -3364,6 +3364,9 @@ handle_control_extendcircuit(control_connection_t *conn, uint32_t len, tor_assert(info); } circuit_append_new_exit(circ, info); + if (circ->build_state->desired_path_len > 1) { + circ->build_state->onehop_tunnel = 0; + } extend_info_free(info); first_node = 0; });