Loading changes/bug40396 0 → 100644 +10 −0 Original line number Diff line number Diff line o Major bugfixes (bridges): - Make Tor work reliably again when you have multiple bridges configured and one or more of them are unreachable. The problem came because we require that we have bridge descriptors for both of our first two bridges (else we refuse to try to connect), but in some cases we would wait three hours before trying to fetch these missing descriptors, and/or never recover when we do try to fetch them. Fixes bugs 40396 and 40495; bugfix on 0.3.0.5-rc and 0.3.2.1-alpha. changes/bug40496 0 → 100644 +6 −0 Original line number Diff line number Diff line o Minor bugfixes (logging): - When we no longer have enough directory information to use the network, we would log a notice-level message -- but we would not reliably log a message when we recovered and resumed using the network. Now make sure there is always a corresponding message about recovering. Fixes bug 40496; bugfix on 0.3.5.1-alpha. changes/bug40497 0 → 100644 +8 −0 Original line number Diff line number Diff line o Minor bugfixes (bridges): - When we don't yet have a descriptor for one of our bridges, disable the entry guard retry schedule on that bridge. The entry guard retry schedule and the bridge descriptor retry schedule can conflict, e.g. where we mark a bridge as "maybe up" yet we don't try to fetch its descriptor yet, leading Tor to wait (refusing to do anything) until it becomes time to fetch the descriptor. Fixes bug 40497; bugfix on 0.3.0.3-alpha. doc/man/tor.1.txt +6 −5 Original line number Diff line number Diff line Loading @@ -3576,14 +3576,15 @@ The following options are used for running a testing Tor network. [[TestingAuthKeySlop]] **TestingAuthKeySlop** __N__ **seconds**|**minutes**|**hours** + [[TestingBridgeBootstrapDownloadInitialDelay]] **TestingBridgeBootstrapDownloadInitialDelay** __N__:: Initial delay in seconds for when clients should download each bridge descriptor when they have just started, or when they can not contact any of their bridges. Initial delay in seconds for how long clients should wait before downloading a bridge descriptor for a new bridge. Changing this requires that **TestingTorNetwork** is set. (Default: 0) [[TestingBridgeDownloadInitialDelay]] **TestingBridgeDownloadInitialDelay** __N__:: Initial delay in seconds for when clients should download each bridge descriptor when they know that one or more of their configured bridges are running. Changing this requires that **TestingTorNetwork** is set. (Default: 10800) How long to wait (in seconds) once clients have successfully downloaded a bridge descriptor, before trying another download for that same bridge. Changing this requires that **TestingTorNetwork** is set. (Default: 10800) [[TestingClientConsensusDownloadInitialDelay]] **TestingClientConsensusDownloadInitialDelay** __N__:: Initial delay in seconds for when clients should download consensuses. Changing this Loading src/feature/client/bridges.c +17 −5 Original line number Diff line number Diff line Loading @@ -943,9 +943,17 @@ rewrite_node_address_for_bridge(const bridge_info_t *bridge, node_t *node) } /** We just learned a descriptor for a bridge. See if that * digest is in our entry guard list, and add it if not. */ * digest is in our entry guard list, and add it if not. Schedule the * next fetch for a long time from now, and initiate any follow-up * activities like continuing to bootstrap. * * <b>from_cache</b> * tells us whether we fetched it from disk (else * the network) * * <b>desc_is_new</b> tells us if we preferred it to the old version we * had, if any. */ void learned_bridge_descriptor(routerinfo_t *ri, int from_cache) learned_bridge_descriptor(routerinfo_t *ri, int from_cache, int desc_is_new) { tor_assert(ri); tor_assert(ri->purpose == ROUTER_PURPOSE_BRIDGE); Loading @@ -961,12 +969,14 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) if (bridge) { /* if we actually want to use this one */ node_t *node; /* it's here; schedule its re-fetch for a long time from now. */ if (!from_cache) { /* This schedules the re-fetch at a constant interval, which produces * a pattern of bridge traffic. But it's better than trying all * configured bridges several times in the first few minutes. */ download_status_reset(&bridge->fetch_status); /* it's here; schedule its re-fetch for a long time from now. */ bridge->fetch_status.next_attempt_at += get_options()->TestingBridgeDownloadInitialDelay; } node = node_get_mutable_by_id(ri->cache_info.identity_digest); Loading @@ -982,7 +992,9 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) entry_guard_learned_bridge_identity(&bridge->addrport_configured, (const uint8_t*)ri->cache_info.identity_digest); log_notice(LD_DIR, "new bridge descriptor '%s' (%s): %s", ri->nickname, if (desc_is_new) log_notice(LD_DIR, "new bridge descriptor '%s' (%s): %s", ri->nickname, from_cache ? "cached" : "fresh", router_describe(ri)); /* If we didn't have a reachable bridge before this one, try directory * documents again. */ Loading Loading
changes/bug40396 0 → 100644 +10 −0 Original line number Diff line number Diff line o Major bugfixes (bridges): - Make Tor work reliably again when you have multiple bridges configured and one or more of them are unreachable. The problem came because we require that we have bridge descriptors for both of our first two bridges (else we refuse to try to connect), but in some cases we would wait three hours before trying to fetch these missing descriptors, and/or never recover when we do try to fetch them. Fixes bugs 40396 and 40495; bugfix on 0.3.0.5-rc and 0.3.2.1-alpha.
changes/bug40496 0 → 100644 +6 −0 Original line number Diff line number Diff line o Minor bugfixes (logging): - When we no longer have enough directory information to use the network, we would log a notice-level message -- but we would not reliably log a message when we recovered and resumed using the network. Now make sure there is always a corresponding message about recovering. Fixes bug 40496; bugfix on 0.3.5.1-alpha.
changes/bug40497 0 → 100644 +8 −0 Original line number Diff line number Diff line o Minor bugfixes (bridges): - When we don't yet have a descriptor for one of our bridges, disable the entry guard retry schedule on that bridge. The entry guard retry schedule and the bridge descriptor retry schedule can conflict, e.g. where we mark a bridge as "maybe up" yet we don't try to fetch its descriptor yet, leading Tor to wait (refusing to do anything) until it becomes time to fetch the descriptor. Fixes bug 40497; bugfix on 0.3.0.3-alpha.
doc/man/tor.1.txt +6 −5 Original line number Diff line number Diff line Loading @@ -3576,14 +3576,15 @@ The following options are used for running a testing Tor network. [[TestingAuthKeySlop]] **TestingAuthKeySlop** __N__ **seconds**|**minutes**|**hours** + [[TestingBridgeBootstrapDownloadInitialDelay]] **TestingBridgeBootstrapDownloadInitialDelay** __N__:: Initial delay in seconds for when clients should download each bridge descriptor when they have just started, or when they can not contact any of their bridges. Initial delay in seconds for how long clients should wait before downloading a bridge descriptor for a new bridge. Changing this requires that **TestingTorNetwork** is set. (Default: 0) [[TestingBridgeDownloadInitialDelay]] **TestingBridgeDownloadInitialDelay** __N__:: Initial delay in seconds for when clients should download each bridge descriptor when they know that one or more of their configured bridges are running. Changing this requires that **TestingTorNetwork** is set. (Default: 10800) How long to wait (in seconds) once clients have successfully downloaded a bridge descriptor, before trying another download for that same bridge. Changing this requires that **TestingTorNetwork** is set. (Default: 10800) [[TestingClientConsensusDownloadInitialDelay]] **TestingClientConsensusDownloadInitialDelay** __N__:: Initial delay in seconds for when clients should download consensuses. Changing this Loading
src/feature/client/bridges.c +17 −5 Original line number Diff line number Diff line Loading @@ -943,9 +943,17 @@ rewrite_node_address_for_bridge(const bridge_info_t *bridge, node_t *node) } /** We just learned a descriptor for a bridge. See if that * digest is in our entry guard list, and add it if not. */ * digest is in our entry guard list, and add it if not. Schedule the * next fetch for a long time from now, and initiate any follow-up * activities like continuing to bootstrap. * * <b>from_cache</b> * tells us whether we fetched it from disk (else * the network) * * <b>desc_is_new</b> tells us if we preferred it to the old version we * had, if any. */ void learned_bridge_descriptor(routerinfo_t *ri, int from_cache) learned_bridge_descriptor(routerinfo_t *ri, int from_cache, int desc_is_new) { tor_assert(ri); tor_assert(ri->purpose == ROUTER_PURPOSE_BRIDGE); Loading @@ -961,12 +969,14 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) if (bridge) { /* if we actually want to use this one */ node_t *node; /* it's here; schedule its re-fetch for a long time from now. */ if (!from_cache) { /* This schedules the re-fetch at a constant interval, which produces * a pattern of bridge traffic. But it's better than trying all * configured bridges several times in the first few minutes. */ download_status_reset(&bridge->fetch_status); /* it's here; schedule its re-fetch for a long time from now. */ bridge->fetch_status.next_attempt_at += get_options()->TestingBridgeDownloadInitialDelay; } node = node_get_mutable_by_id(ri->cache_info.identity_digest); Loading @@ -982,7 +992,9 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) entry_guard_learned_bridge_identity(&bridge->addrport_configured, (const uint8_t*)ri->cache_info.identity_digest); log_notice(LD_DIR, "new bridge descriptor '%s' (%s): %s", ri->nickname, if (desc_is_new) log_notice(LD_DIR, "new bridge descriptor '%s' (%s): %s", ri->nickname, from_cache ? "cached" : "fresh", router_describe(ri)); /* If we didn't have a reachable bridge before this one, try directory * documents again. */ Loading