stop calling channel_mark_client in response to a create_fast

since all it does is produce false positives

this commit should get merged into 0.2.9 and 0.3.0 *and* 0.3.1, even
though the code in the previous commit is already present in 0.3.1. sorry
for the mess.

[Cherry-picked]

diff --git a/changes/bug24898-029 b/changes/bug24898-029
new file mode 100644 (file)
index 0000000..b33f093
--- /dev/null
+++ b/changes/bug24898-029
@@ -0,0 +1,6 @@
+  o Minor bugfixes (relay):
+    - Make the internal channel_is_client() function look at what sort
+      of connection handshake the other side used, rather than whether
+      the other side ever sent a create_fast cell to us. Backports part
+      of the fixes from bugs 22805 and 24898.
+

diff --git a/src/or/command.c b/src/or/command.c
index 894483e0013959f7c07bf56a6a29a53f68000d16..e7eb0716101709abb1fe55f1d1dc50cdaa2f40b5 100644 (file)
--- a/src/or/command.c
+++ b/src/or/command.c
@@ -347,16 +347,6 @@ command_process_create_cell(cell_t *cell, channel_t *chan)
     int len;
     created_cell_t created_cell;
 
-    /* If the client used CREATE_FAST, it's probably a tor client or bridge
-     * relay, and we must not use it for EXTEND requests (in most cases, we
-     * won't have an authenticated peer ID for the extend).
-     * Public relays on 0.2.9 and later will use CREATE_FAST if they have no
-     * ntor onion key for this relay, but that should be a rare occurrence.
-     * Clients on 0.3.1 and later avoid using CREATE_FAST as much as they can,
-     * even during bootstrap, so the CREATE_FAST check is most accurate for
-     * earlier tor client versions. */
-    channel_mark_client(chan);
-
     memset(&created_cell, 0, sizeof(created_cell));
     len = onion_skin_server_handshake(ONION_HANDSHAKE_TYPE_FAST,
                                        create_cell->onionskin,