Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#7656 closed defect (fixed)

Stop automated redundant tor browser requests; disable network.http.connection-retry-timeout

Reported by: cypherpunks Owned by: mikeperry
Priority: Medium Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: MikePerry201302 tbb-pref
Cc: asn, adrelanos@… Actual Points: 1
Parent ID: Points:
Reviewer: Sponsor:

Description

Firefox accelerates HTTP connection timeout. See https://bugzilla.mozilla.org/show_bug.cgi?id=592284

For TorBroswer:
No sense to launch parallel connection after 250ms by default, and no logic to tweak it. As long as Tor client retries stream buildings too, any "high" level timeouts makes not so much profit and probably do things much worse.
Right now it overloads network and relay exits in first place with waste connection request.
TBB must disable it by setting network.http.connection-retry-timeout to 0.

Child Tickets

Change History (27)

comment:1 Changed 7 years ago by cypherpunks

Resolution: invalid
Status: newclosed

comment:2 Changed 7 years ago by mikeperry

Cc: asn added

What's going on here? Is this a real bug or not? At a glance, it looks like this only applies to native socket transports, not proxies. Is that why you marked it invalid? What about #7657?

Did someone else mark your bugs invalid?

comment:3 in reply to:  2 ; Changed 7 years ago by rransom

Resolution: invalid
Status: closedreopened

Replying to mikeperry:

What's going on here? Is this a real bug or not? At a glance, it looks like this only applies to native socket transports, not proxies. Is that why you marked it invalid? What about #7657?

Did someone else mark your bugs invalid?

This ticket and #7657 look like they were created by the bug-eating ‘troll’ with many names, who then closed them because he/she/it was annoyed that you hadn't fixed them within 36 hours.

comment:4 in reply to:  3 Changed 7 years ago by asn

Priority: criticalnormal

Replying to rransom:

Replying to mikeperry:

What's going on here? Is this a real bug or not? At a glance, it looks like this only applies to native socket transports, not proxies. Is that why you marked it invalid? What about #7657?

Did someone else mark your bugs invalid?

This ticket and #7657 look like they were created by the bug-eating ‘troll’ with many names, who then closed them because he/she/it was annoyed that you hadn't fixed them within 36 hours.

This is my impression too. I think he/she/it tried to pull a #1240 where you close valid tickets after some hours without any reason.

Downgrading the priority to reduce the troll factor.

comment:5 Changed 7 years ago by cypherpunks

Priority: normalblocker

comment:6 Changed 7 years ago by arma

<oftc_must_be_destroyed> because it overloaded by firefox attempt second conn
> hey, speaking of which. has anybody tracked down when and why that firefox-second-attempt happens?
> (and can we turn it off?)
<oftc_must_be_destroyed> yes we can!
<oftc_must_be_destroyed> everything tracked
<oftc_must_be_destroyed> but nobody cares
<oftc_must_be_destroyed> #7656
> fun. does that behavior happen when there's a proxy set too?
> "At a glance, it looks like this only applies to native socket transports, not proxies"
<oftc_must_be_destroyed> yes
<oftc_must_be_destroyed> happen
> i guess it is especially bad for tor, since it very likely just reuses the same circuit as the first request
<oftc_must_be_destroyed> yes

Looks like http://hg.mozilla.org/mozilla-central/rev/be4b69a4babf is where the dreaded "feature" went into Firefox. Turning it off does indeed sound like a wise plan.

comment:7 Changed 7 years ago by arma

Summary: Save network, delete polluting, disable network.http.connection-retry-timeoutStop automated redundant tor browser requests; disable network.http.connection-retry-timeout

comment:8 Changed 7 years ago by arma

I hacked my Tor client to track things better:

@@ -1256,7 +1257,7 @@ connection_handle_listener_read(connection_t *conn, int new_type)
     connection_mark_for_close(conn);
     return -1;
   }
-  log_debug(LD_NET,
+  log_notice(LD_NET,
             "Connection accepted on socket %d (child of fd %d).",
             (int)news,(int)conn->s);
 diff --git a/src/or/relay.c b/src/or/relay.c
index a942e44..26a2699 100644
--- a/src/or/relay.c
+++ b/src/or/relay.c
@@ -1619,6 +1619,13 @@ connection_edge_package_raw_inbuf(edge_connection_t *conn, int package_partial,
             conn->base_.s,
             (int)length, (int)connection_get_inbuf_len(TO_CONN(conn)));
 
+  if (conn->base_.type == CONN_TYPE_AP) {
+    char *text = tor_memdup(payload, length+1);
+    text[length] = 0;
+    log_notice(LD_APP, "Incoming socks text:===\n%s\n===", text);
+    tor_free(text);
+  }
+
   if (sending_optimistically && !sending_from_optimistic) {
     /* This is new optimistic data; remember it in case we need to detach and
        retry */

And a fetch in my tor browser for http://freehaven.net/~arma/cv.html results in

Jan 14 02:05:05.000 [notice] Connection accepted on socket 14 (child of fd 6).
Jan 14 02:05:05.000 [notice] Connection accepted on socket 15 (child of fd 6).
Jan 14 02:05:06.000 [notice] Incoming socks text:===
GET /~arma/cv.html HTTP/1.1
Host: freehaven.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive


===

So it would seem that I am getting two socks connections (as expected), but only one of them generates an http request onto the circuit.

So perhaps this issue isn't so bad after all.

comment:9 in reply to:  8 Changed 7 years ago by arma

Replying to arma:

So it would seem that I am getting two socks connections (as expected)

Turning network.http.connection-retry-timeout to 0 means I get only one socks connection for the fetch (as expected).

comment:10 in reply to:  8 Changed 7 years ago by cypherpunks

So it would seem that I am getting two socks connections (as expected), but only one of them generates an http request onto the circuit.

So perhaps this issue isn't so bad after all.

You could to try some https link too. Both connections tries to do TLS handshake, it's not so good while people tries to use https everywhere.

comment:11 Changed 7 years ago by cypherpunks

Resolution: worksforme
Status: reopenedclosed

"ignore it until someone proves it to me" -- mikeperry

denoise it. >.<

comment:12 Changed 7 years ago by arma

Resolution: worksforme
Status: closedreopened

Still an issue. Please don't close tickets just because people haven't thoroughly investigated the issue yet.

comment:13 Changed 7 years ago by cypherpunks

How so?

comment:14 Changed 7 years ago by cypherpunks

If people can't reproduce it what a thoroughly investigation are you waiting for?

comment:15 Changed 7 years ago by cypherpunks

Just close it, thats all. Browsers is for localhost, nobody care one extra connection per localhost.

comment:16 Changed 7 years ago by cypherpunks

ignore it until someone proves it to me

What a bundle did you used? Did you changed default options?

comment:17 Changed 7 years ago by cypherpunks

And now we opens club of anonymous ircholics. thanks.
Hello people. I'm ircholic and my host banned by oftc. thanks.

comment:18 Changed 7 years ago by cypherpunks

I'm ircholic and my host banned by oftc.

Yep, you need to try not to chat at all, you need to use forums or tracs.

comment:19 Changed 7 years ago by cypherpunks

you need to use forums or trac

Nice idea. I'll try to use this trac.

comment:20 Changed 7 years ago by cypherpunks

my host banned by oftc

you can to use browser and some irc2web gateways.

comment:21 Changed 7 years ago by cypherpunks

I had create #7955 to investigate censorship event by oftc.

comment:22 Changed 7 years ago by cypherpunks

fuck. just close this fucking ticket if nobody fucking can read 3 lines diff for code and realize what it does.

comment:23 Changed 7 years ago by cypherpunks

Resolution: fixed
Status: reopenedclosed

comment:24 Changed 6 years ago by proper

Cc: adrelanos@… added
Priority: blockernormal
Resolution: fixed
Status: closedreopened

The bug closing troll is now hopefully gone.

No idea about priority, so I reset it to what asn has set it earlier.

comment:25 Changed 6 years ago by mikeperry

Actual Points: 1
Keywords: MikePerry201302 tbb-pref added
Resolution: fixed
Status: reopenedclosed

This pref is set in TBB-2.3.25-4. It had been set in TBB-alpha for the past two releases. I stopped commenting on the ticket because there was no point in trying to discuss this here with so much trolling and other self-conflicting nonsense. It certainly would have gotten fixed in TBB-stable faster without quite so much of that.

For future reference, such behavior is the *absolute best* way to get me to ignore a ticket.

comment:26 Changed 6 years ago by cypherpunks

Folks your troll detector broken, you better to fix it early.

If you can't read source code and to reproduce it then no need to find another reason for explanations.

comment:27 Changed 6 years ago by cypherpunks

proper, you better to go away hopefully too.

Note: See TracTickets for help on using tickets.