summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGeorge Kadianakis <desnacked@riseup.net>2017-03-02 16:28:11 +0200
committerNick Mathewson <nickm@torproject.org>2017-03-09 09:19:19 -0500
commit6cab0f8ad712def4f5a9bdfb9d11b0e773f7f76a (patch)
tree295c07b0673da7539ac21d2ac52bdb7e8ecc0982
parent41324b5ae1334a40baa87785ad18d1a4d9df5322 (diff)
downloadtor-6cab0f8ad712def4f5a9bdfb9d11b0e773f7f76a.tar.gz
tor-6cab0f8ad712def4f5a9bdfb9d11b0e773f7f76a.zip
Fix failing bridges+ipv6-min integration test.
The bridges+ipv6-min integration test has a client with bridges: Bridge 127.0.0.1:5003 Bridge [::1]:5003 which got stuck in guard_selection_have_enough_dir_info_to_build_circuits() because it couldn't find the descriptor of both bridges. Specifically, the guard_has_descriptor() function could not find the node_t of the [::1] bridge, because the [::1] bridge had no identity digest assigned to it. After further examination, it seems that during fetching the descriptor for our bridges, we used the CERTS cell to fill the identity digest of 127.0.0.1:5003 properly. However, when we received a CERTS cell from [::1]:5003 we actually ignored its identity digest because the learned_router_identity() function was using get_configured_bridge_by_addr_port_digest() which was returning the 127.0.0.1 bridge instead of the [::1] bridge (because it prioritizes digest matching over addrport matching). The fix replaces get_configured_bridge_by_addr_port_digest() with the recent get_configured_bridge_by_exact_addr_port_digest() function. It also relaxes the constraints of the get_configured_bridge_by_exact_addr_port_digest() function by making it return bridges whose identity digest is not yet known. By using the _exact_() function, learned_router_identity() actually fills in the identity digest of the [::1] bridge, which then allows guard_has_descriptor() to find the right node_t and verify that the descriptor is there. FWIW, in the bridges+ipv6-min test both 127.0.0.1 and [::1] bridges correspond to the same node_t, which I guess makes sense given that it's actually the same underlying bridge.
-rw-r--r--src/or/bridges.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/src/or/bridges.c b/src/or/bridges.c
index f766931b46..88154c6c8a 100644
--- a/src/or/bridges.c
+++ b/src/or/bridges.c
@@ -218,7 +218,7 @@ get_configured_bridge_by_exact_addr_port_digest(const tor_addr_t *addr,
if (digest && tor_memeq(bridge->identity, digest, DIGEST_LEN))
return bridge;
- else if (!digest)
+ else if (!digest || tor_digest_is_zero(bridge->identity))
return bridge;
}
@@ -297,7 +297,7 @@ learned_router_identity(const tor_addr_t *addr, uint16_t port,
(void)ed_id;
int learned = 0;
bridge_info_t *bridge =
- get_configured_bridge_by_addr_port_digest(addr, port, digest);
+ get_configured_bridge_by_exact_addr_port_digest(addr, port, digest);
if (bridge && tor_digest_is_zero(bridge->identity)) {
memcpy(bridge->identity, digest, DIGEST_LEN);
learned = 1;