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

added MikePerry201302 actualpoints::1 component::torbrowserbutton owner::mikeperry priority::medium resolution::fixed status::closed tbb-pref type::defect labels

Trac:
Status: new to closed
Resolution: N/A to invalid

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 (closed)?

Did someone else mark your bugs invalid?

Trac:
Cc: N/A to asn

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 (closed)?

Did someone else mark your bugs invalid?

This ticket and #7657 (closed) 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.

Trac:
Resolution: invalid to N/A
Status: closed to reopened

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 (closed)?

Did someone else mark your bugs invalid?

This ticket and #7657 (closed) 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 (moved) where you close valid tickets after some hours without any reason.

Downgrading the priority to reduce the troll factor.

Trac:
Priority: critical to normal

Trac:
Priority: normal to blocker

<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.

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

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.

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).

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.

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

denoise it. >.<

Trac:
Resolution: N/A to worksforme
Status: reopened to closed

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

Trac:
Resolution: worksforme to N/A
Status: closed to reopened

How so?

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

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

ignore it until someone proves it to me

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

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

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.

you need to use forums or trac

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

my host banned by oftc

you can to use browser and some irc2web gateways.

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

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

Trac:
Resolution: N/A to fixed
Status: reopened to closed

The bug closing troll is now hopefully gone.

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

Trac:
Priority: blocker to normal
Status: closed to reopened
Resolution: fixed to N/A
Cc: asn to asn, adrelanos@riseup.net

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.

Trac:
Keywords: N/A deleted, MikePerry201302 tbb-pref added
Status: reopened to closed
Actualpoints: N/A to 1
Resolution: N/A to fixed

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.

proper, you better to go away hopefully too.

closed

added 8h of time spent

mentioned in issue tpo/applications/tor-browser#40783 (closed)

mentioned in issue tpo/applications/tor-browser#32759

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

Child items 0

Activity