[tor-commits] [tor/release-0.3.0] Fix failing bridges+ipv6-min integration test.

nickm at torproject.org nickm at torproject.org
Mon Apr 3 13:29:32 UTC 2017


commit 6cab0f8ad712def4f5a9bdfb9d11b0e773f7f76a
Author: George Kadianakis <desnacked at riseup.net>
Date:   Thu Mar 2 16:28:11 2017 +0200

    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.
---
 src/or/bridges.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/or/bridges.c b/src/or/bridges.c
index f766931..88154c6 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;





More information about the tor-commits mailing list