April 2014 - tor-commits - lists.torproject.org

r26735: {website} Adding Sreenatha's GSoC project (website/trunk/about/en)
by Damian Johnson 24 Apr '14

24 Apr '14

Author: atagar Date: 2014-04-24 16:06:12 +0000 (Thu, 24 Apr 2014) New Revision: 26735 Modified: website/trunk/about/en/gsoc.wml Log: Adding Sreenatha's GSoC project Modified: website/trunk/about/en/gsoc.wml =================================================================== --- website/trunk/about/en/gsoc.wml 2014-04-24 14:57:39 UTC (rev 26734) +++ website/trunk/about/en/gsoc.wml 2014-04-24 16:06:12 UTC (rev 26735) @@ -217,6 +217,7 @@ <li><h4><a href="https://ahmia.fi/gsoc/">Ahmia.fi - Search Engine for Hidden Services</a> by Juha Nurmi</h4></li> <li><h4><a href="http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/amoghbl1…">Orbot & Orfox</a> by Amogh Pradeep</h4></li> <li><h4><a href="http://ileiva.github.io/gettor_proposal.html">Revamp GetTor</a> by Israel Leiva</h4></li> + <li><h4><a href="https://sites.google.com/site/sreenathadev/gsoc-2014-weather-rewrite">Weather Rewrite</a> by Sreenatha Bhatlapenumarthi</h4></li> <li><h4><a href="http://kostas.mkj.lt/gsoc2014/gsoc2014.html">BridgeDB Distributor</a> by Kostas Jakeliunas</h4></li> <li><h4><a href="http://kostas.mkj.lt/gsoc2013/gsoc2013.html">Searchable Tor descriptor archive</a> by Kostas Jakeliunas</h4></li> <li><h4><a href="https://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/weltrau…">Create an Internet Censorship Virtual Machine Based Simulator</a> by Johannes Fürmann</h4></li>

1 0

r26734: {website} more torbutton references to clean up. (in website/trunk: about/en docs/torbutton/en getinvolved/en projects/en)
by Andrew Lewman 24 Apr '14

24 Apr '14

Author: phobos Date: 2014-04-24 14:57:39 +0000 (Thu, 24 Apr 2014) New Revision: 26734 Modified: website/trunk/about/en/contributors.wml website/trunk/about/en/corepeople.wml website/trunk/docs/torbutton/en/index.wml website/trunk/docs/torbutton/en/sidenav.wmi website/trunk/docs/torbutton/en/torbutton-faq.wml website/trunk/docs/torbutton/en/torbutton-options.wml website/trunk/getinvolved/en/translation-overview.wml website/trunk/getinvolved/en/volunteer.wml website/trunk/projects/en/sidenav.wmi Log: more torbutton references to clean up. Modified: website/trunk/about/en/contributors.wml =================================================================== --- website/trunk/about/en/contributors.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/about/en/contributors.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -82,7 +82,7 @@ to measure various properties of the Tor network; mentored by Mike Perry.</dd> <dt>Scott Squires</dt><dd>The original developer of <a -href="<page torbutton/index>">Torbutton</a>.</dd> +href="<page docs/torbutton/index>">Torbutton</a>.</dd> <dt>tup (a pseudonym)</dt><dd>Added new features for making Tor easier to use as a <a href="<wiki>TransparentProxy">transparent Modified: website/trunk/about/en/corepeople.wml =================================================================== --- website/trunk/about/en/corepeople.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/about/en/corepeople.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -283,7 +283,7 @@ <dt>Mike Perry, Tor Browser and Tor Performance Developer</dt> <dd>Lead developer on Tor Browser, developer - of <a href="<page torbutton/index>">Torbutton</a>, author of <a + of <a href="<page docs/torbutton/index>">Torbutton</a>, author of <a href="https://gitweb.torproject.org/torflow.git/blob/HEAD:/README">TorFlow</a>. Runs one of the directory authorities.</dd> Modified: website/trunk/docs/torbutton/en/index.wml =================================================================== --- website/trunk/docs/torbutton/en/index.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/docs/torbutton/en/index.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -6,7 +6,7 @@ <div id="content" class="clearfix"> <div id="breadcrumbs"> <a href="<page index>">Home » </a> - <a href="<page torbutton/index>">Torbutton</a> + <a href="<page docs/torbutton/index>">Torbutton</a> </div> <div id="maincol">  Modified: website/trunk/docs/torbutton/en/sidenav.wmi =================================================================== --- website/trunk/docs/torbutton/en/sidenav.wmi 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/docs/torbutton/en/sidenav.wmi 2014-04-24 14:57:39 UTC (rev 26734) @@ -91,7 +91,7 @@ {'url' => 'docs/faq', 'txt' => 'General FAQ', }, - {'url' => 'torbutton/torbutton-faq', + {'url' => 'docs/torbutton/torbutton-faq', 'txt' => 'Torbutton FAQ', }, {'url' => 'docs/faq-abuse', Modified: website/trunk/docs/torbutton/en/torbutton-faq.wml =================================================================== --- website/trunk/docs/torbutton/en/torbutton-faq.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/docs/torbutton/en/torbutton-faq.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -6,8 +6,8 @@ <div id="content" class="clearfix"> <div id="breadcrumbs"> <a href="<page index>">Home » </a> - <a href="<page torbutton/index>">Torbutton » </a> - <a href="<page torbutton/torbutton-faq>">Torbutton FAQ</a> + <a href="<page docs/torbutton/index>">Torbutton » </a> + <a href="<page docs/torbutton/torbutton-faq>">Torbutton FAQ</a> </div> <div id="maincol">  Modified: website/trunk/docs/torbutton/en/torbutton-options.wml =================================================================== --- website/trunk/docs/torbutton/en/torbutton-options.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/docs/torbutton/en/torbutton-options.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -6,8 +6,8 @@ <div id="content" class="clearfix"> <div id="breadcrumbs"> <a href="<page index>">Home » </a> - <a href="<page torbutton/index>">Torbutton » </a> - <a href="<page torbutton/torbutton-options>">Torbutton Options</a> + <a href="<page docs/torbutton/index>">Torbutton » </a> + <a href="<page docs/torbutton/torbutton-options>">Torbutton Options</a> </div> <div id="maincol">  Modified: website/trunk/getinvolved/en/translation-overview.wml =================================================================== --- website/trunk/getinvolved/en/translation-overview.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/getinvolved/en/translation-overview.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -23,7 +23,7 @@ The Tor bundles include several different programs, all of which need translation help. In order of importance they are: <a href="<page projects/vidalia>">Vidalia</a>, - <a href="<page torbutton/index>">Torbutton</a>, and + <a href="<page docs/torbutton/index>">Torbutton</a>, and <a href="https://check.torproject.org/">TorCheck</a>. You can also help translate the Vidalia help files, the Vidalia installer, Torbutton, <a href="<page docs/android>">Orbot</a>, and <a href="<page Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/getinvolved/en/volunteer.wml 2014-04-24 14:57:39 UTC (rev 26734) @@ -472,7 +472,7 @@ </p> <a id="project-torbutton"></a> - <h3><a href="<page torbutton/index>">Torbutton</a> (<a + <h3><a href="<page docs/torbutton/index>">Torbutton</a> (<a href="https://gitweb.torproject.org/torbutton.git">code</a>, <a href="https://trac.torproject.org/projects/tor/query?status=accepted&status=assig…">bug tracker</a>)</h3> @@ -2187,7 +2187,7 @@ puzzles the right answer? What other practical approaches are there? Bonus if they're backward-compatible with the current Tor protocol.</li> <li>Programs like <a - href="<page torbutton/index>">Torbutton</a> aim to hide + href="<page docs/torbutton/index>">Torbutton</a> aim to hide your browser's UserAgent string by replacing it with a uniform answer for every Tor user. That way the attacker can't splinter Tor's anonymity set by looking at that header. It tries to pick a string that is commonly used Modified: website/trunk/projects/en/sidenav.wmi =================================================================== --- website/trunk/projects/en/sidenav.wmi 2014-04-24 14:50:48 UTC (rev 26733) +++ website/trunk/projects/en/sidenav.wmi 2014-04-24 14:57:39 UTC (rev 26734) @@ -26,9 +26,6 @@ {'url' => 'projects/projects', 'txt' => 'Software & Services', 'subelements' => [ - {'url' => 'torbutton/index', - 'txt' => 'TorButton', - }, {'url' => 'projects/torbrowser', 'txt' => 'Tor Browser Bundle', },

1 0

r26733: {website} actually, fix the FAQ too (website/trunk/docs/en)
by Andrew Lewman 24 Apr '14

24 Apr '14

Author: phobos Date: 2014-04-24 14:50:48 +0000 (Thu, 24 Apr 2014) New Revision: 26733 Modified: website/trunk/docs/en/faq.wml Log: actually, fix the FAQ too Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2014-04-24 14:45:24 UTC (rev 26732) +++ website/trunk/docs/en/faq.wml 2014-04-24 14:50:48 UTC (rev 26733) @@ -1341,11 +1341,6 @@ Chrome/IE/Opera/etc with Tor.</a></h3> <p> -Unfortunately, Torbutton only works with Firefox right now, and without -<a href="<page docs/torbutton/en/design/>">Torbutton's -extensive privacy fixes</a> there are many ways for websites or other -attackers to recognize you, track you back to your IP address, and so -on. In short, using any browser besides Tor Browser Bundle with Tor is a really bad idea. </p> @@ -1353,11 +1348,9 @@ <p> We're working with the Chrome team to <a href="https://blog.torproject.org/blog/google-chrome-incognito-mode-tor- -and-fingerprinting">fix -some bugs and missing APIs in Chrome</a> so it will be possible to write -a -Torbutton for Chrome. No support for any other browser is on the -horizon. +and-fingerprinting">fix some bugs and missing APIs in Chrome</a> so it +will be possible to write a Torbutton for Chrome. No support for any +other browser is on the horizon. </p> <hr> @@ -1367,7 +1360,10 @@ Will Torbutton be available for other browsers?</a></h3> <p> - We don't support IE, Opera or Safari and never plan to. There are too many ways that your privacy can go wrong with those browsers, and because of their closed design it is really hard for us to do anything to change these privacy problems. + We don't support IE, Opera or Safari and never plan to. There are + too many ways that your privacy can go wrong with those browsers, and + because of their closed design it is really hard for us to do anything + to change these privacy problems. </p> <p> We are working with the Chrome people to modify Chrome's internals so that we can eventually support it. But for now, Firefox is the only safe choice.

1 0

[tor/master] Merge remote-tracking branch 'public/bug11553_024' into bug11553_025
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit bd169aa9a512857fe95fa0cbe44e4e6dbc2c800f Merge: eb896d5 0d75344 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 18 13:00:45 2014 -0400 Merge remote-tracking branch 'public/bug11553_024' into bug11553_025 Conflicts: src/or/channel.h changes/bug11553 | 15 ++++++++++++++ src/or/channel.c | 3 --- src/or/channel.h | 7 ++----- src/or/circuitbuild.c | 52 ++++++++++++++++++++++++++++++++++--------------- src/or/connection.c | 2 -- 5 files changed, 53 insertions(+), 26 deletions(-) diff --cc src/or/channel.h index 7ec222d,e63c949..de19fad --- a/src/or/channel.h +++ b/src/or/channel.h @@@ -146,19 -145,16 +146,16 @@@ struct channel_s * When we send CREATE cells along this connection, which half of the * space should we use? */ - ENUM_BF(circ_id_type_t) circ_id_type:2; + circ_id_type_bitfield_t circ_id_type:2; /** DOCDOC*/ unsigned wide_circ_ids:1; - /** - * Which circ_id do we try to use next on this connection? This is - * always in the range 0..1<<15-1. - */ - circid_t next_circ_id; + /** Have we logged a warning about circID exhaustion on this channel? */ + unsigned warned_circ_ids_exhausted:1; - /* For how many circuits are we n_chan? What about p_chan? */ + /** For how many circuits are we n_chan? What about p_chan? */ unsigned int num_n_circuits, num_p_circuits; - /* + /** * True iff this channel shouldn't get any new circs attached to it, * because the connection is too old, or because there's a better one. * More generally, this flag is used to note an unhealthy connection;

1 0

[tor/master] Diagnostic warning to see if it's pending destroys causing 11553
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit 47a0c10728712cbfa3683f218b9379299b968636 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 18 13:04:37 2014 -0400 Diagnostic warning to see if it's pending destroys causing 11553 --- src/or/circuitbuild.c | 16 +++++++++++++--- src/or/circuitlist.c | 14 +++++++++++--- 2 files changed, 24 insertions(+), 6 deletions(-) diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index e1d57ad..e4e8115 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -88,7 +88,8 @@ static circid_t get_unique_circ_id_by_chan(channel_t *chan) { #define MAX_CIRCID_ATTEMPTS 64 - + int in_use; + unsigned n_with_circ = 0, n_pending_destroy = 0; circid_t test_circ_id; circid_t attempts=0; circid_t high_bit, max_range, mask; @@ -126,9 +127,12 @@ get_unique_circ_id_by_chan(channel_t *chan) chan->warned_circ_ids_exhausted = 1; log_warn(LD_CIRC,"No unused circIDs found on channel %s wide " "circID support, with %u inbound and %u outbound circuits. " + "Found %u circuit IDs in use by circuits, and %u with " + "pending destroy cells." "Failing a circuit.", chan->wide_circ_ids ? "with" : "without", - chan->num_p_circuits, chan->num_n_circuits); + chan->num_p_circuits, chan->num_n_circuits, + n_with_circ, n_pending_destroy); } return 0; } @@ -136,7 +140,13 @@ get_unique_circ_id_by_chan(channel_t *chan) crypto_rand((char*) &test_circ_id, sizeof(test_circ_id)); test_circ_id &= mask; test_circ_id |= high_bit; - } while (circuit_id_in_use_on_channel(test_circ_id, chan)); + + in_use = circuit_id_in_use_on_channel(test_circ_id, chan); + if (in_use == 1) + ++n_with_circ; + else if (in_use == 2) + ++n_pending_destroy; + } while (in_use); return test_circ_id; } diff --git a/src/or/circuitlist.c b/src/or/circuitlist.c index b71dc3c..8a8fc8b 100644 --- a/src/or/circuitlist.c +++ b/src/or/circuitlist.c @@ -1065,13 +1065,21 @@ circuit_get_by_circid_channel_even_if_marked(circid_t circ_id, } /** Return true iff the circuit ID <b>circ_id</b> is currently used by a - * circuit, marked or not, on <b>chan</b>. */ + * circuit, marked or not, on <b>chan</b>, or if the circ ID is reserved until + * a queued destroy cell can be sent. + * + * (Return 1 if the circuit is present, marked or not; Return 2 + * if the circuit ID is pending a destroy.) + **/ int circuit_id_in_use_on_channel(circid_t circ_id, channel_t *chan) { int found = 0; - return circuit_get_by_circid_channel_impl(circ_id, chan, &found) != NULL - || found; + if (circuit_get_by_circid_channel_impl(circ_id, chan, &found) != NULL) + return 1; + if (found) + return 2; + return 0; } /** Return the circuit that a given edge connection is using. */

1 0

[tor/master] Supply better and less frequent warnings on circID exhaustion
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit bb9b4c37f8e7f5cf78918f382e90d8b11ff42551 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 18 12:28:30 2014 -0400 Supply better and less frequent warnings on circID exhaustion Fixes the surface behavior of #11553 --- changes/bug11553 | 5 +++++ src/or/channel.h | 2 ++ src/or/circuitbuild.c | 9 ++++++++- 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/changes/bug11553 b/changes/bug11553 new file mode 100644 index 0000000..1540f46 --- /dev/null +++ b/changes/bug11553 @@ -0,0 +1,5 @@ + o Minor features: + - When we run out of usable circuit IDs on a channel, log only one + warning for the whole channel, and include a description of + how many circuits there were on the channel. Fix for part of ticket + #11553. diff --git a/src/or/channel.h b/src/or/channel.h index 2dca817..29ba40e 100644 --- a/src/or/channel.h +++ b/src/or/channel.h @@ -148,6 +148,8 @@ struct channel_s { ENUM_BF(circ_id_type_t) circ_id_type:2; /** DOCDOC*/ unsigned wide_circ_ids:1; + /** Have we logged a warning about circID exhaustion on this channel? */ + unsigned warned_circ_ids_exhausted:1; /* * Which circ_id do we try to use next on this connection? This is * always in the range 0..1<<15-1. diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index e47a278..2b4d3c3 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -127,7 +127,14 @@ get_unique_circ_id_by_chan(channel_t *chan) /* Make sure we don't loop forever if all circ_id's are used. This * matters because it's an external DoS opportunity. */ - log_warn(LD_CIRC,"No unused circ IDs. Failing."); + if (! chan->warned_circ_ids_exhausted) { + chan->warned_circ_ids_exhausted = 1; + log_warn(LD_CIRC,"No unused circIDs found on channel %s wide " + "circID support, with %u inbound and %u outbound circuits. " + "Failing a circuit.", + chan->wide_circ_ids ? "with" : "without", + chan->num_p_circuits, chan->num_n_circuits); + } return 0; } test_circ_id |= high_bit;

1 0

[tor/master] Switch to random allocation on circuitIDs.
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit 0d75344b0e0eafc89db89a974e87b16564cd8f0a Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 18 12:50:04 2014 -0400 Switch to random allocation on circuitIDs. Fixes a possible root cause of 11553 by only making 64 attempts at most to pick a circuitID. Previously, we would test every possible circuit ID until we found one or ran out. This algorithm succeeds probabilistically. As the comment says: This potentially causes us to give up early if our circuit ID space is nearly full. If we have N circuit IDs in use, then we will reject a new circuit with probability (N / max_range) ^ MAX_CIRCID_ATTEMPTS. This means that in practice, a few percent of our circuit ID capacity will go unused. The alternative here, though, is to do a linear search over the whole circuit ID space every time we extend a circuit, which is not so great either. This makes new vs old clients distinguishable, so we should try to batch it with other patches that do that, like 11438. --- changes/bug11553 | 10 ++++++++++ src/or/channel.c | 3 --- src/or/channel.h | 5 ----- src/or/circuitbuild.c | 43 ++++++++++++++++++++++++++++--------------- src/or/connection.c | 2 -- 5 files changed, 38 insertions(+), 25 deletions(-) diff --git a/changes/bug11553 b/changes/bug11553 index 1540f46..ed30ce9 100644 --- a/changes/bug11553 +++ b/changes/bug11553 @@ -3,3 +3,13 @@ warning for the whole channel, and include a description of how many circuits there were on the channel. Fix for part of ticket #11553. + + + o Major features (performance): + - Avoid wasting cycles looking for usable circuit IDs. Previously, + when allocating a new circuit ID, we would in the worst case do a + linear scan over the entire possible range of circuit IDs before + deciding that we had exhausted our possibilities. Now, we + try 64 circuit IDs at random before deciding that we probably + won't succeed. Fix for a possible root cause of ticket + #11553. diff --git a/src/or/channel.c b/src/or/channel.c index 1270eac..dfef703 100644 --- a/src/or/channel.c +++ b/src/or/channel.c @@ -731,9 +731,6 @@ channel_init(channel_t *chan) /* Init timestamp */ chan->timestamp_last_added_nonpadding = time(NULL); - /* Init next_circ_id */ - chan->next_circ_id = crypto_rand_int(1 << 15); - /* Initialize queues. */ TOR_SIMPLEQ_INIT(&chan->incoming_queue); TOR_SIMPLEQ_INIT(&chan->outgoing_queue); diff --git a/src/or/channel.h b/src/or/channel.h index 29ba40e..e63c949 100644 --- a/src/or/channel.h +++ b/src/or/channel.h @@ -150,11 +150,6 @@ struct channel_s { unsigned wide_circ_ids:1; /** Have we logged a warning about circID exhaustion on this channel? */ unsigned warned_circ_ids_exhausted:1; - /* - * Which circ_id do we try to use next on this connection? This is - * always in the range 0..1<<15-1. - */ - circid_t next_circ_id; /* For how many circuits are we n_chan? What about p_chan? */ unsigned int num_n_circuits, num_p_circuits; diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 2b4d3c3..1b3c599 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -92,18 +92,21 @@ channel_connect_for_circuit(const tor_addr_t *addr, uint16_t port, return chan; } -/** Iterate over values of circ_id, starting from conn-\>next_circ_id, - * and with the high bit specified by conn-\>circ_id_type, until we get - * a circ_id that is not in use by any other circuit on that conn. + +/** Search for a value for circ_id that we can use on <b>chan</b> for an + * outbound circuit, until we get a circ_id that is not in use by any other + * circuit on that conn. * * Return it, or 0 if can't get a unique circ_id. */ static circid_t get_unique_circ_id_by_chan(channel_t *chan) { +#define MAX_CIRCID_ATTEMPTS 64 + circid_t test_circ_id; circid_t attempts=0; - circid_t high_bit, max_range; + circid_t high_bit, max_range, mask; tor_assert(chan); @@ -113,19 +116,26 @@ get_unique_circ_id_by_chan(channel_t *chan) "a client with no identity."); return 0; } - max_range = (chan->wide_circ_ids) ? (1u<<31) : (1u<<15); + max_range = (chan->wide_circ_ids) ? (1u<<31) : (1u<<15); + mask = max_range - 1; high_bit = (chan->circ_id_type == CIRC_ID_TYPE_HIGHER) ? max_range : 0; do { - /* Sequentially iterate over test_circ_id=1...max_range until we find a - * circID such that (high_bit|test_circ_id) is not already used. */ - test_circ_id = chan->next_circ_id++; - if (test_circ_id == 0 || test_circ_id >= max_range) { - test_circ_id = 1; - chan->next_circ_id = 2; - } - if (++attempts > max_range) { - /* Make sure we don't loop forever if all circ_id's are used. This - * matters because it's an external DoS opportunity. + if (++attempts > MAX_CIRCID_ATTEMPTS) { + /* Make sure we don't loop forever because all circuit IDs are used. + * + * Once, we would try until we had tried every possible circuit ID. But + * that's quite expensive. Instead, we try MAX_CIRCID_ATTEMPTS random + * circuit IDs, and then give up. + * + * This potentially causes us to give up early if our circuit ID space + * is nearly full. If we have N circuit IDs in use, then we will reject + * a new circuit with probability (N / max_range) ^ MAX_CIRCID_ATTEMPTS. + * This means that in practice, a few percent of our circuit ID capacity + * will go unused. + * + * The alternative here, though, is to do a linear search over the + * whole circuit ID space every time we extend a circuit, which is + * not so great either. */ if (! chan->warned_circ_ids_exhausted) { chan->warned_circ_ids_exhausted = 1; @@ -137,6 +147,9 @@ get_unique_circ_id_by_chan(channel_t *chan) } return 0; } + + crypto_rand((char*) &test_circ_id, sizeof(test_circ_id)); + test_circ_id &= mask; test_circ_id |= high_bit; } while (circuit_id_in_use_on_channel(test_circ_id, chan)); return test_circ_id; diff --git a/src/or/connection.c b/src/or/connection.c index 4f74a1d..96e6a47 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -251,8 +251,6 @@ dir_connection_new(int socket_family) * * Set timestamp_last_added_nonpadding to now. * - * Assign a pseudorandom next_circ_id between 0 and 2**15. - * * Initialize active_circuit_pqueue. * * Set active_circuit_pqueue_last_recalibrated to current cell_ewma tick.

1 0

[tor/master] Add a rate-limiter for the other circuitID exhaustion warning
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit 985deaaaf7b7397857e02206e89392e0ee101077 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Apr 18 13:22:42 2014 -0400 Add a rate-limiter for the other circuitID exhaustion warning --- src/or/circuitbuild.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 1b3c599..7b852ff 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -596,7 +596,9 @@ circuit_deliver_create_cell(circuit_t *circ, const create_cell_t *create_cell, id = get_unique_circ_id_by_chan(circ->n_chan); if (!id) { - log_warn(LD_CIRC,"failed to get unique circID."); + static ratelim_t circid_warning_limit = RATELIM_INIT(9600); + log_fn_ratelim(&circid_warning_limit, LOG_WARN, LD_CIRC, + "failed to get unique circID."); return -1; } log_debug(LD_CIRC,"Chosen circID %u.", (unsigned)id);

1 0

[tor/master] Merge remote-tracking branch 'public/bug11553_025'
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit 5a9ac0df99158f870f6cebc781337652b419cca9 Merge: 67aa368 17ad309 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 24 10:48:32 2014 -0400 Merge remote-tracking branch 'public/bug11553_025' changes/bug11553 | 15 ++++++++++ src/or/channel.c | 4 +-- src/or/channel.h | 9 +++--- src/or/circuitbuild.c | 75 +++++++++++++++++++++++++++++++++++++------------ src/or/circuitlist.c | 14 +++++++-- src/or/connection.c | 2 -- 6 files changed, 89 insertions(+), 30 deletions(-)

1 0

[tor/master] Improvements to #11553 fix based on review
by nickm＠torproject.org 24 Apr '14

24 Apr '14

commit a770b74501a3faf6483c40735b70adae6fb95187 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 23 12:39:01 2014 -0400 Improvements to #11553 fix based on review Use a per-channel ratelim_t to control the rate at which we report failures for each channel. Explain why I picked N=32. Never return a zero circID. Thanks to Andrea and to cypherpunks. --- src/or/channel.c | 3 +++ src/or/channel.h | 6 ++++-- src/or/circuitbuild.c | 19 +++++++++++++------ 3 files changed, 20 insertions(+), 8 deletions(-) diff --git a/src/or/channel.c b/src/or/channel.c index dfef703..691da17 100644 --- a/src/or/channel.c +++ b/src/or/channel.c @@ -731,6 +731,9 @@ channel_init(channel_t *chan) /* Init timestamp */ chan->timestamp_last_added_nonpadding = time(NULL); + /* Warn about exhausted circuit IDs no more than hourly. */ + chan->last_warned_circ_ids_exhausted.rate = 3600; + /* Initialize queues. */ TOR_SIMPLEQ_INIT(&chan->incoming_queue); TOR_SIMPLEQ_INIT(&chan->outgoing_queue); diff --git a/src/or/channel.h b/src/or/channel.h index e63c949..63da0c1 100644 --- a/src/or/channel.h +++ b/src/or/channel.h @@ -148,8 +148,6 @@ struct channel_s { ENUM_BF(circ_id_type_t) circ_id_type:2; /** DOCDOC*/ unsigned wide_circ_ids:1; - /** Have we logged a warning about circID exhaustion on this channel? */ - unsigned warned_circ_ids_exhausted:1; /* For how many circuits are we n_chan? What about p_chan? */ unsigned int num_n_circuits, num_p_circuits; @@ -178,6 +176,10 @@ struct channel_s { */ unsigned int is_local:1; + /** Have we logged a warning about circID exhaustion on this channel? + * If so, when? */ + ratelim_t last_warned_circ_ids_exhausted; + /** Channel timestamps for cell channels */ time_t timestamp_client; /* Client used this, according to relay.c */ time_t timestamp_drained; /* Output queue empty */ diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c index 7b852ff..8d6aad6 100644 --- a/src/or/circuitbuild.c +++ b/src/or/circuitbuild.c @@ -102,6 +102,12 @@ channel_connect_for_circuit(const tor_addr_t *addr, uint16_t port, static circid_t get_unique_circ_id_by_chan(channel_t *chan) { +/* This number is chosen somewhat arbitrarily; see comment below for more + * info. When the space is 80% full, it gives a one-in-a-million failure + * chance; when the space is 90% full, it gives a one-in-850 chance; and when + * the space is 95% full, it gives a one-in-26 failure chance. That seems + * okay, though you could make a case IMO for anything between N=32 and + * N=256. */ #define MAX_CIRCID_ATTEMPTS 64 circid_t test_circ_id; @@ -137,19 +143,20 @@ get_unique_circ_id_by_chan(channel_t *chan) * whole circuit ID space every time we extend a circuit, which is * not so great either. */ - if (! chan->warned_circ_ids_exhausted) { - chan->warned_circ_ids_exhausted = 1; - log_warn(LD_CIRC,"No unused circIDs found on channel %s wide " + log_fn_ratelim(&chan->last_warned_circ_ids_exhausted, LOG_WARN, + LD_CIRC,"No unused circIDs found on channel %s wide " "circID support, with %u inbound and %u outbound circuits. " "Failing a circuit.", chan->wide_circ_ids ? "with" : "without", chan->num_p_circuits, chan->num_n_circuits); - } return 0; } - crypto_rand((char*) &test_circ_id, sizeof(test_circ_id)); - test_circ_id &= mask; + do { + crypto_rand((char*) &test_circ_id, sizeof(test_circ_id)); + test_circ_id &= mask; + } while (test_circ_id == 0); + test_circ_id |= high_bit; } while (circuit_id_in_use_on_channel(test_circ_id, chan)); return test_circ_id;

1 0