tor-commits April 2011

tor-commits@lists.torproject.org

18 participants
883 discussions

[tor/maint-0.2.2] Fix up some cell-queue stats issues in rephist.c
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 71fb2af62c0a60fee94f984b782531a5d492b055 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 14:56:50 2011 -0400 Fix up some cell-queue stats issues in rephist.c - Document the structure and variables. - Make circuits_for_buffer_stats into a static variable. - Don't die horribly if interval_length is 0. - Remove the unused local_circ_id field. - Reorder the fields of circ_buffer_stats_t for cleaner alignment layout. --- src/or/rephist.c | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/or/rephist.c b/src/or/rephist.c index e56ce9e..74e156f 100644 --- a/src/or/rephist.c +++ b/src/or/rephist.c @@ -2330,14 +2330,19 @@ rep_hist_buffer_stats_init(time_t now) start_of_buffer_stats_interval = now; } +/** Statistics from a single circuit. Collected when the circuit closes, or + * when we flush statistics to disk. */ typedef struct circ_buffer_stats_t { - uint32_t processed_cells; + /** Average number of cells in the circuit's queue */ double mean_num_cells_in_queue; + /** Average time a cell waits in the queue. */ double mean_time_cells_in_queue; - uint32_t local_circ_id; + /** Total number of cells sent over this circuit */ + uint32_t processed_cells; } circ_buffer_stats_t; -smartlist_t *circuits_for_buffer_stats = NULL; +/** List of circ_buffer_stats_t. */ +static smartlist_t *circuits_for_buffer_stats = NULL; /** Remember cell statistics for circuit <b>circ</b> at time * <b>end_of_interval</b> and reset cell counters in case the circuit @@ -2361,6 +2366,8 @@ rep_hist_buffer_stats_add_circ(circuit_t *circ, time_t end_of_interval) circ->timestamp_created.tv_sec : start_of_buffer_stats_interval; interval_length = (int) (end_of_interval - start_of_interval); + if (interval_length <= 0) + return; stat = tor_malloc_zero(sizeof(circ_buffer_stats_t)); stat->processed_cells = orcirc->processed_cells; /* 1000.0 for s -> ms; 2.0 because of app-ward and exit-ward queues */

1 0

[tor/master] Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 70e02914682eb1959d8b385f76b5acf7486158cc Author: Gisle Vanem <gvanem(a)broadpark.no> Date: Thu Apr 7 18:34:11 2011 -0400 Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests --- changes/win_tmp_dir | 4 ++++ src/test/test.c | 14 ++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/changes/win_tmp_dir b/changes/win_tmp_dir new file mode 100644 index 0000000..13f6e7f --- /dev/null +++ b/changes/win_tmp_dir @@ -0,0 +1,4 @@ + o Unit tests: + - Use GetTempDir to find the proper temporary directory location on + Windows when generating temporary files for the unit tests. Patch + by Gisle Vanem. diff --git a/src/test/test.c b/src/test/test.c index f5b6a22..9b24a99 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -84,10 +84,16 @@ setup_directory(void) if (is_setup) return; #ifdef MS_WINDOWS - // XXXX - tor_snprintf(temp_dir, sizeof(temp_dir), - "c:\\windows\\temp\\tor_test_%d", (int)getpid()); - r = mkdir(temp_dir); + { + char buf[MAX_PATH]; + const char *tmp = buf; + /* If this fails, we're probably screwed anyway */ + if (!GetTempPath(sizeof(buf),buf)) + tmp = "c:\\windows\\temp"; + tor_snprintf(temp_dir, sizeof(temp_dir), + "%s\\tor_test_%d", tmp, (int)getpid()); + r = mkdir(temp_dir); + } #else tor_snprintf(temp_dir, sizeof(temp_dir), "/tmp/tor_test_%d", (int) getpid()); r = mkdir(temp_dir, 0700);

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 08 Apr '11

08 Apr '11

commit 85ac832a1474e274ff4a6ad9444cf5e0ab12450e Merge: 67d88a7 70e0291 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 20:27:39 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' changes/win_tmp_dir | 4 ++++ src/test/test.c | 14 ++++++++++---- 2 files changed, 14 insertions(+), 4 deletions(-)

1 0

[tor/maint-0.2.2] Use GetTempDir instead of hardcoded path to c:\windows\tmp for unittests
by nickm＠torproject.org 08 Apr '11

08 Apr '11

1 0

[metrics-web/master] Add Roger's blog post to the papers page.
by karsten＠torproject.org 07 Apr '11

07 Apr '11

commit 2d1a8c13b918b5c411a3e2756e3172aed31dbd97 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Thu Apr 7 21:32:45 2011 +0200 Add Roger's blog post to the papers page. --- web/WEB-INF/papers.jsp | 21 +++++++++++++++++---- 1 files changed, 17 insertions(+), 4 deletions(-) diff --git a/web/WEB-INF/papers.jsp b/web/WEB-INF/papers.jsp index 1880483..50f8bda 100644 --- a/web/WEB-INF/papers.jsp +++ b/web/WEB-INF/papers.jsp @@ -12,10 +12,11 @@ <div class="main-column"> <h2>Tor Metrics Portal: Papers</h2> <br> - <p>The <a href="#papers">papers</a> and - <a href="#techreports">technical reports</a> listed on this page - originate from, or are based on, work performed in the Tor Metrics - Project.</p> + <p>The <a href="#papers">papers</a>, + <a href="#techreports">technical reports</a>, and + <a href="#blogposts">blog posts</a> listed on this page originate + from, are based on, or are related to work performed in the Tor + Metrics Project.</p> <br> <a name="papers"></a> <h3>Papers</h3> @@ -81,6 +82,18 @@ (<a href="papers/dirarch-2009-06-22.pdf">PDF</a>, 558K, last updated on June 22, 2009).</li> </ul> + <br> + <a name="blogposts"></a> + <h3>Blog posts</h3> + <br> + The following blog posts are either the results of metrics + research or describe new interesting research questions that can + (partly) be answered with metrics data. + <ul> + <li>Research problem: measuring the safety of the Tor network + (<a href="https://blog.torproject.org/blog/research-problem-measuring-safety-tor-netw…">link</a>, + February 5, 2011).</li> + </ul> </div> </div> <div class="bottom" id="bottom">

1 0

[torspec/master] add mike's triangle boy analysis
by arma＠torproject.org 07 Apr '11

07 Apr '11

commit 3b5b8804f64a4db7ec7fc0185ea1afb7a2713797 Author: Roger Dingledine <arma(a)torproject.org> Date: Thu Apr 7 12:35:28 2011 -0400 add mike's triangle boy analysis --- proposals/ideas/xxx-triangleboy-transport.txt | 194 +++++++++++++++++++++++++ 1 files changed, 194 insertions(+), 0 deletions(-) diff --git a/proposals/ideas/xxx-triangleboy-transport.txt b/proposals/ideas/xxx-triangleboy-transport.txt new file mode 100644 index 0000000..e09eaac --- /dev/null +++ b/proposals/ideas/xxx-triangleboy-transport.txt @@ -0,0 +1,194 @@ +[See also http://archives.seul.org/tor/dev/Feb-2011/msg00000.html and +its follow-ups.] + +Filename: ideas/xxx-triangleboy-transport.txt +Title: The Triangle Boy Transport +Author: Mike Perry +Created: 31-Jan-2011 +Status: Draft + + +Introduction + +In this proposal, we describe a transport plugin known as the Triangle +Boy transport: +http://www.webrant.com/safeweb_site/html/www/tboy_whitepaper.html + +The basic idea is to be able to utilize an asymmetric residential IP +with minimal CPU and memory resources, and limited upstream. We would +use the bridge for only half of the stream, avoiding the upstream +bottleneck of most residential connections. The return direction +will be spoofed by a supporting high-capacity Tor relay. + + +Overview + +The high level packet flow diagram would look like this. + + Client -> Client Plugin -> Transport Bridge -> Relay Plugin -> Relay + Client <- Client Plugin <--(spoof)--- Relay Plugin <- Relay + +Testing in the field has demonstrated that most residential +connections also perform egress filtering, where as many colo centers +do not. This means that the spoofing logic needs to be present at the +Relay endpoint, and not in the Transport Bridge (though the Transport +Bridge will still need raw sockets to listen for TCP fragments). + +It is this egress filter constraint that requires that this transport +use the pluggable-transport spec, as opposed to creating a very simple +spoofing Transport Bridge. + +There are two possible designs for the operation of the Transport +Bridge. The bridge can either be peered with a relay of its choosing, +or it can be peered with a client-specified relay. Since using a +client-specified relay in a censored location is prone to failure due +to unobservable changing network conditions, we will consider the case +where the Transport Bridge chooses which relay to forward the +connections to. + +The client will use the Transport Bridge IP with a bridge line like: + "bridge TriangleBoy address:port" + +On the client side, the TriangleBoy transport keyword would only mean +that the Tor client should not try to cache the identity key of the +bridge in question, nor should it perform any strict checks to ensure +that the IP reported by the relay is consistent or matches its +endpoint. + +Other than these basic loosened constraints, it should be able to use +the Transport Bridge IP as if it were any other bridge. This is +uniquely different from the what the pluggable-transport spec assumes. +Most of the complexity involved in supporting this transport will be +in the Transport Bridge, and in the Relay Plugin side of the equation. + + +Transport Bridge Operation + +The Transport Bridge will require raw sockets to operate. It will also +require a tor client to fetch and authenticate the Tor directory. + +The current pluggable transport spec suggests that extrainfo +descriptors be used to describe which transport plugins a bridge +supports. This would require that the Transport Bridge set +DownloadExtraInfo=1 in its torrc. + +The extrainfo document would need to list the following information: +TriangleBoyTransport ip:port +TriangleBoyCert <Certificate> + +The Transport Bridge would attempt to select an appropriate relay or +relays to forward all client connections. + +The forwarding operation by the Transport Bridge would involve a TLS +connection to the ip and port specified in the extrainfo document and +authenticated by the certificate there, and speak cells of the +following format: + + <data_len>: 2 bytes + <data>: data_len bytes + +Each new raw TCP packet that arrives at the transport bridge would be +packaged up according to this scheme. The data portion of the packet +would be the raw IP frame received by the transport bridge. + +The TLS connection can be reused to multiplex many different raw +datagrams for many different clients. + + +Relay Plugin Startup + +Not all relays can support the TriangleBoy transport. Many relays are +behind egress filters that will prevent the transmission of spoofed +packets. The transport plugin should be robust enough to be able to +determine if it can properly spoof the packets. This involves both +ensuring that the plugin process has sufficient permissions, and also +sending some spoofed test packets to a server to receive the response. + +If either of these tests fail, the plugin needs to inform Tor of this +fact so that Tor does *not* provide the lines for the TriangleBoy +transport in its extrainfo document. + +The relay would configure the plugin using its torrc: + +ServerTransportPlugin TriangleBoy /path/to/triangleboy ip=<ip> port=<port> \ + tor_ip=<ip> tor_port=<port> free_rfc1918=<ip> + +Tor would launch the triangleboy process, which would perform the +appropriate uid checks, and send test spoofed packets to $SERVER (the +bridgedb?). If the tests pass, it would reply with: + +SMETHOD: TriangleBoy <ip>:<port> \ + EXTRAINFO:TriangleBoyTransport=<ip>:<port>,TriangleBoyCert=<Certificate> +METHODS: DONE + +If there are any errors with permissions or spoofing, the transport +should reply with: + +METHODS: NONE + +and then exit. + + +Relay Plugin Operation + +The relay plugin will listen for TLS connections on its port, using +the certificate it created and sent to Tor during startup. + +It will perform some verification on the integrity of incoming +datagrams: ensuring that they are in fact TCP/IP, that their destination +IP was in fact the Transport Bridge, and that their source IP is in +publicly routable IP space. + +It would then perform a form of NAT in order to translate the raw IP +frames coming in to be sourced from the free_rfc1918 IP (specified in +the configuration line) and a random free port. It will maintain an +internal mapping between these randomized local source ports and the +originating Client IP and port (as well as the Transport Bridge IP). + +The Relay will then proceed believing that it has a TCP connection +from an unused, local rfc1918 ip and source port. This ip+port will +not actually exist, but instead will be handled by a raw socket +listening in the Relay Plugin. + +Upon receiving packets from the Tor process on its raw socket, the +Relay Plugin will use the destination port to look up the original +Client IP and port, and the Transport Bridge IP. It will rewrite the +packets to spoof the source IP as the Transport Bridge IP, and set the +destination IP and port as the one it found for the Client in the its +NAT table. + +In this way, the NAT will properly seamlessly translate packets for +the Relay, and the Client will communicate with what it believes to be +the Transport Bridge IP, while using the capacity of the supporting +Tor Relay for the downstream direction. + + +Appendix: List of key xxx-pluggable-transport.txt shortcomings + +1. This pluggable transport does not need any intelligence or process +launching on the Client side, aside from a way to tell Tor not to be +so pedantic about ensuring identity key and IP address consistency. + +2. The relay side needs to be able to detect if it has both the +permissions and the network ability to send spoofed packets. It needs +to communicate this fact with the Relay Plugin by responding with the +appropriate extrainfo lines, or with "METHODS: NONE" to indicate +error. This relay-side handshake should be specified in the +pluggable-transport spec. + +3. The relay plugin side needs some way to communicate EXTRAINFO lines +to be added to its extrainfo descriptor. In this proposal, we use the +SMETHOD reply to do this. + +4. Is extrainfo really the best place to keep this information? +Shouldn't it just be in the relay/bridge descriptor? Putting it in +extrainfo requires our TransportBridges to enable the wasteful +DownloadExtraInfo=1 torrc setting, which will consume more scarce +resources and RAM on what will probably be cheap routers with 32-64M +of RAM. + +5. How would we go about chaining an actual obfuscation mechanism with +this transport? Would we just create new and separate transport called +TriangleBoyOverHTTP, for example, or is there a better way to chain +different mechanisms? +

1 0

[tor/master] Add a missing cast to silence the compiler
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit 8d81831d715adf9cb374100e23cc2b118efe3101 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Mar 28 18:20:50 2011 +0200 Add a missing cast to silence the compiler --- src/or/connection.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/connection.c b/src/or/connection.c index 084237d..6e7bbd5 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -2790,7 +2790,7 @@ connection_handle_write_impl(connection_t *conn, int force) edge_connection_t *edge_conn = TO_EDGE_CONN(conn); /* Check for overflow: */ if (PREDICT_LIKELY(UINT32_MAX - edge_conn->n_written > n_written)) - edge_conn->n_written += n_written; + edge_conn->n_written += (int)n_written; else edge_conn->n_written = UINT32_MAX; }

1 0

[tor/master] Merge remote-tracking branch 'public/xxx_fixups' into maint-0.2.2
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit ba0cd8094f8e6ae0113ad69958d9d0973bb1f2c3 Merge: 118d8ff fc64783 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 12:03:04 2011 -0400 Merge remote-tracking branch 'public/xxx_fixups' into maint-0.2.2 Conflicts: src/or/or.h changes/bug539_removal | 6 +++ changes/connect_err_reporting | 6 +++ changes/count_overflow | 5 +++ changes/full_ap_circuits | 6 +++ changes/kill_ftime | 7 ++++ changes/noroute | 5 +++ src/common/address.c | 20 ++++++----- src/common/compat_libevent.c | 17 +++------ src/common/memarea.c | 7 +++- src/common/util.c | 77 ----------------------------------------- src/common/util.h | 10 ----- src/or/buffers.c | 6 ++-- src/or/circuitbuild.c | 9 +++-- src/or/circuitlist.c | 3 ++ src/or/circuituse.c | 5 ++- src/or/config.c | 6 ++-- src/or/connection.c | 36 ++++++++++++------- src/or/connection_edge.c | 30 +++++++++++----- src/or/connection_or.c | 6 +++- src/or/directory.c | 37 ++++++++------------ src/or/dirserv.c | 11 ++++-- src/or/dns.c | 2 +- src/or/dnsserv.c | 2 +- src/or/eventdns.c | 2 +- src/or/geoip.c | 5 ++- src/or/networkstatus.c | 11 ++++-- src/or/or.h | 12 +++++-- src/or/reasons.c | 8 +---- src/or/relay.c | 2 + src/or/rendclient.c | 4 +- src/or/rendcommon.c | 2 +- src/or/rephist.c | 2 +- src/or/routerlist.c | 18 +++++----- src/or/routerparse.c | 2 +- 34 files changed, 184 insertions(+), 203 deletions(-) diff --cc src/or/or.h index 3cadd31,e44c626..1688a08 --- a/src/or/or.h +++ b/src/or/or.h @@@ -2126,9 -2126,16 +2126,15 @@@ typedef struct circuit_t * length ONIONSKIN_CHALLENGE_LEN. */ char *n_conn_onionskin; - time_t timestamp_created; /**< When was this circuit created? */ + struct timeval timestamp_created; /**< When was the circuit created? */ - time_t timestamp_dirty; /**< When the circuit was first used, or 0 if the - * circuit is clean. */ + /** When the circuit was first used, or 0 if the circuit is clean. + * + * XXXX023 Note that some code will artifically adjust this value backward + * in time in order to indicate that a circuit shouldn't be used for new + * streams, but that it can stay alive as long as it has streams on it. + * That's a kludge we should fix. + */ + time_t timestamp_dirty; - struct timeval highres_created; /**< When exactly was the circuit created? */ uint16_t marked_for_close; /**< Should we close this circuit at the end of * the main loop? (If true, holds the line number

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit 67d88a7d6021e95a2d423a9f26811accd1da39b6 Merge: 07ab483 ba0cd80 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Apr 7 12:17:20 2011 -0400 Merge remote-tracking branch 'origin/maint-0.2.2' Conflicts: src/common/address.c src/common/compat_libevent.c src/common/memarea.c src/common/util.h src/or/buffers.c src/or/circuitbuild.c src/or/circuituse.c src/or/connection.c src/or/directory.c src/or/networkstatus.c src/or/or.h src/or/routerlist.c changes/bug539_removal | 6 ++++++ changes/connect_err_reporting | 6 ++++++ changes/count_overflow | 5 +++++ changes/full_ap_circuits | 6 ++++++ changes/kill_ftime | 7 +++++++ changes/noroute | 5 +++++ src/common/address.c | 20 ++++++++++++-------- src/common/address.h | 2 +- src/common/compat_libevent.c | 21 ++++++--------------- src/common/memarea.c | 6 ++++-- src/common/util.h | 18 ------------------ src/or/buffers.c | 7 +++++++ src/or/circuitbuild.c | 7 ++++--- src/or/circuitlist.c | 3 +++ src/or/circuituse.c | 5 +++-- src/or/config.c | 6 +++--- src/or/connection.c | 37 +++++++++++++++++++++++-------------- src/or/connection_edge.c | 30 +++++++++++++++++++++--------- src/or/connection_or.c | 6 +++++- src/or/directory.c | 38 +++++++++++++++----------------------- src/or/dirserv.c | 11 +++++++---- src/or/dns.c | 2 +- src/or/dnsserv.c | 2 +- src/or/eventdns.c | 2 +- src/or/geoip.c | 5 +++-- src/or/networkstatus.c | 11 ++++++++--- src/or/or.h | 12 +++++++++--- src/or/reasons.c | 8 +------- src/or/relay.c | 2 ++ src/or/rendclient.c | 4 ++-- src/or/rendcommon.c | 2 +- src/or/rephist.c | 2 +- src/or/routerlist.c | 16 ++++++++-------- src/or/routerparse.c | 2 +- 34 files changed, 188 insertions(+), 134 deletions(-) diff --cc src/or/circuituse.c index 5488eb7,cdf49e3..e58d5e0 --- a/src/or/circuituse.c +++ b/src/or/circuituse.c @@@ -1277,10 -1284,11 +1277,11 @@@ circuit_get_open_circ_or_launch(edge_co return -1; } } else { - /* XXXX022 Duplicates checks in connection_ap_handshake_attach_circuit */ + /* XXXX023 Duplicates checks in connection_ap_handshake_attach_circuit: + * refactor into a single function? */ - routerinfo_t *router = router_get_by_nickname(conn->chosen_exit_name, 1); + const node_t *node = node_get_by_nickname(conn->chosen_exit_name, 1); int opt = conn->chosen_exit_optional; - if (router && !connection_ap_can_use_exit(conn, router, 0)) { + if (node && !connection_ap_can_use_exit(conn, node, 0)) { log_fn(opt ? LOG_INFO : LOG_WARN, LD_APP, "Requested exit point '%s' would refuse request. %s.", conn->chosen_exit_name, opt ? "Trying others" : "Closing"); diff --cc src/or/connection.c index 8b48b96,6e7bbd5..02ae7ee --- a/src/or/connection.c +++ b/src/or/connection.c @@@ -2746,15 -2575,19 +2747,19 @@@ connection_read_to_buf(connection_t *co n_read = (size_t) result; } - if (n_read > 0) { /* change *max_to_read */ - /*XXXX022 check for overflow*/ - *max_to_read = (int)(at_most - n_read); - } + if (n_read > 0) { - /* change *max_to_read */ ++ /* change *max_to_read */ + *max_to_read = at_most - n_read; - if (conn->type == CONN_TYPE_AP) { - edge_connection_t *edge_conn = TO_EDGE_CONN(conn); - /*XXXX022 check for overflow*/ - edge_conn->n_read += (int)n_read; + /* Update edge_conn->n_read */ + if (conn->type == CONN_TYPE_AP) { + edge_connection_t *edge_conn = TO_EDGE_CONN(conn); + /* Check for overflow: */ + if (PREDICT_LIKELY(UINT32_MAX - edge_conn->n_read > n_read)) + edge_conn->n_read += (int)n_read; + else + edge_conn->n_read = UINT32_MAX; + } } connection_buckets_decrement(conn, approx_time(), n_read, n_written); @@@ -3145,10 -2786,13 +3150,14 @@@ connection_handle_write_impl(connection n_written = (size_t) result; } - if (conn->type == CONN_TYPE_AP) { + if (n_written && conn->type == CONN_TYPE_AP) { edge_connection_t *edge_conn = TO_EDGE_CONN(conn); - /*XXXX022 check for overflow.*/ - edge_conn->n_written += (int)n_written; ++ + /* Check for overflow: */ + if (PREDICT_LIKELY(UINT32_MAX - edge_conn->n_written > n_written)) + edge_conn->n_written += (int)n_written; + else + edge_conn->n_written = UINT32_MAX; } connection_buckets_decrement(conn, approx_time(), n_read, n_written); diff --cc src/or/directory.c index 3b1fb02,8f33a60..6bef581 --- a/src/or/directory.c +++ b/src/or/directory.c @@@ -1602,27 -1539,19 +1602,19 @@@ connection_dir_client_reached_eof(dir_c (void) skewed; /* skewed isn't used yet. */ if (status_code == 503) { - if (body_len < 16) { - routerstatus_t *rs; - trusted_dir_server_t *ds; - log_info(LD_DIR,"Received http status code %d (%s) from server " - "'%s:%d'. I'll try again soon.", - status_code, escaped(reason), conn->_base.address, - conn->_base.port); - rs = router_get_mutable_consensus_status_by_id(conn->identity_digest); - if (rs) - rs->last_dir_503_at = now; - if ((ds = router_get_trusteddirserver_by_digest(conn->identity_digest))) - ds->fake_status.last_dir_503_at = now; + routerstatus_t *rs; + trusted_dir_server_t *ds; + log_info(LD_DIR,"Received http status code %d (%s) from server " + "'%s:%d'. I'll try again soon.", + status_code, escaped(reason), conn->_base.address, + conn->_base.port); - if ((rs = router_get_consensus_status_by_id(conn->identity_digest))) ++ if ((rs = router_get_mutable_consensus_status_by_id(conn->identity_digest))) + rs->last_dir_503_at = now; + if ((ds = router_get_trusteddirserver_by_digest(conn->identity_digest))) + ds->fake_status.last_dir_503_at = now; - tor_free(body); tor_free(headers); tor_free(reason); - return -1; - } - /* XXXX022 Remove this once every server with bug 539 is obsolete. */ - log_info(LD_DIR, "Server at '%s:%d' sent us a 503 response, but included " - "a body anyway. We'll pretend it gave us a 200.", - conn->_base.address, conn->_base.port); - status_code = 200; + tor_free(body); tor_free(headers); tor_free(reason); + return -1; } plausible = body_is_plausible(body, body_len, conn->_base.purpose); diff --cc src/or/networkstatus.c index 6387126,4f6fe15..50982d7 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@@ -1807,11 -1765,15 +1808,15 @@@ networkstatus_set_current_consensus(con write_str_to_file(consensus_fname, consensus, 0); } - if (time_definitely_before(now, c->valid_after, 60)) { + /** If a consensus appears more than this many seconds before its declared + * valid-after time, declare that our clock is skewed. */ + #define EARLY_CONSENSUS_NOTICE_SKEW 60 + + if (now < current_consensus->valid_after - EARLY_CONSENSUS_NOTICE_SKEW) { char tbuf[ISO_TIME_LEN+1]; char dbuf[64]; - long delta = now - current_consensus->valid_after; - format_iso_time(tbuf, current_consensus->valid_after); + long delta = now - c->valid_after; + format_iso_time(tbuf, c->valid_after); format_time_interval(dbuf, sizeof(dbuf), delta); log_warn(LD_GENERAL, "Our clock is %s behind the time published in the " "consensus network status document (%s GMT). Tor needs an " diff --cc src/or/or.h index c134d7c,1688a08..56d701b --- a/src/or/or.h +++ b/src/or/or.h @@@ -2279,12 -2126,15 +2279,18 @@@ typedef struct circuit_t * length ONIONSKIN_CHALLENGE_LEN. */ char *n_conn_onionskin; - struct timeval timestamp_created; /**< When was the circuit created? */ + /** When was this circuit created? We keep this timestamp with a higher + * resolution than most so that the circuit-build-time tracking code can + * get millisecond resolution. */ + struct timeval timestamp_created; - time_t timestamp_dirty; /**< When the circuit was first used, or 0 if the - * circuit is clean. */ + /** When the circuit was first used, or 0 if the circuit is clean. + * + * XXXX023 Note that some code will artifically adjust this value backward + * in time in order to indicate that a circuit shouldn't be used for new + * streams, but that it can stay alive as long as it has streams on it. + * That's a kludge we should fix. + */ + time_t timestamp_dirty; uint16_t marked_for_close; /**< Should we close this circuit at the end of * the main loop? (If true, holds the line number diff --cc src/or/routerlist.c index 1205fd1,4deff53..580763d --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@@ -1764,9 -1768,9 +1764,9 @@@ smartlist_choose_node_by_bandwidth_weig weighted_bw += weight*this_bw; if (is_me) sl_last_weighted_bw_of_me = weight*this_bw; - } + } SMARTLIST_FOREACH_END(node); - /* XXXX022 this is a kludge to expose these values. */ + /* XXXX023 this is a kludge to expose these values. */ sl_last_total_weighted_bw = weighted_bw; log_debug(LD_CIRC, "Choosing node for rule %s based on weights " @@@ -1874,21 -1883,20 +1874,21 @@@ smartlist_choose_node_by_bandwidth(smar int is_known = 1; int32_t flags = 0; uint32_t this_bw = 0; - if (statuses) { - status = smartlist_get(sl, i); - if (router_digest_is_me(status->identity_digest)) - me_idx = i; - router = router_get_by_digest(status->identity_digest); - is_exit = status->is_exit; - is_guard = status->is_possible_guard; - if (status->has_bandwidth) { - this_bw = kb_to_bytes(status->bandwidth); + i = node_sl_idx; + + if (router_digest_is_me(node->identity)) + me_idx = node_sl_idx; + + is_exit = node->is_exit; + is_guard = node->is_possible_guard; + if (node->rs) { + if (node->rs->has_bandwidth) { + this_bw = kb_to_bytes(node->rs->bandwidth); } else { /* guess */ - /* XXX022 once consensuses always list bandwidths, we can take + /* XXX023 once consensuses always list bandwidths, we can take * this guessing business out. -RD */ is_known = 0; - flags = status->is_fast ? 1 : 0; + flags = node->rs->is_fast ? 1 : 0; flags |= is_exit ? 2 : 0; flags |= is_guard ? 4 : 0; } @@@ -4686,13 -4606,10 +4686,13 @@@ update_router_descriptor_downloads(time if (directory_fetches_dir_info_early(options)) { update_router_descriptor_cache_downloads_v2(now); } + update_consensus_router_descriptor_downloads(now, 0, - networkstatus_get_reasonably_live_consensus(now)); + networkstatus_get_reasonably_live_consensus(now, FLAV_NS)); - /* XXXX021 we could be smarter here; see notes on bug 652. */ + /* XXXX023 we could be smarter here; see notes on bug 652. */ + /* XXXX NM Microdescs: if we're not fetching microdescriptors, we need + * to make something else invoke this. */ /* If we're a server that doesn't have a configured address, we rely on * directory fetches to learn when our address changes. So if we haven't * tried to get any routerdescs in a long time, try a dummy fetch now. */

1 0

[tor/master] Send END_STREAM_REASON_NOROUTE: clients that didn't grok it are now obsolete
by nickm＠torproject.org 07 Apr '11

07 Apr '11

commit fc647832783cab352bebba63fe0210d7be395058 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 28 13:42:59 2011 -0400 Send END_STREAM_REASON_NOROUTE: clients that didn't grok it are now obsolete --- changes/noroute | 5 +++++ src/or/reasons.c | 8 +------- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/changes/noroute b/changes/noroute new file mode 100644 index 0000000..644deec --- /dev/null +++ b/changes/noroute @@ -0,0 +1,5 @@ + - Minor features + - Send END_STREAM_REASON_NOROUTE in response to EHOSTUNREACH errors. + Clients before 0.2.1.27 didn't handle NOROUTE correctly, but + such clients are already deprecated because of security bugs. + diff --git a/src/or/reasons.c b/src/or/reasons.c index 27c947e..319e6c0 100644 --- a/src/or/reasons.c +++ b/src/or/reasons.c @@ -174,13 +174,7 @@ errno_to_stream_end_reason(int e) S_CASE(ENETUNREACH): return END_STREAM_REASON_INTERNAL; S_CASE(EHOSTUNREACH): - /* XXXX023 - * The correct behavior is END_STREAM_REASON_NOROUTE, but older - * clients don't recognize it. So we're going to continue sending - * "MISC" until 0.2.1.27 or later is "well established". - */ - /* return END_STREAM_REASON_NOROUTE; */ - return END_STREAM_REASON_MISC; + return END_STREAM_REASON_NOROUTE; S_CASE(ECONNREFUSED): return END_STREAM_REASON_CONNECTREFUSED; S_CASE(ECONNRESET):

1 0

← Newer
1
...
68
69
70
71
72
73
74
...
89
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2011