[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: AdvTor

Fabian Keil wrote:
Anon Mus <my.green.lantern@xxxxxxxxxxxxxx> wrote:

andrew@xxxxxxxxxxxxxx wrote:
On Thu, Oct 07, 2010 at 05:20:08PM +0100, my.green.lantern@xxxxxxxxxxxxxx wrote 2.3K bytes in 55 lines about:
: Well, well, well.... suddenly the problem fixes "itself"... after
: 20+ disconnects and 10+ "You are using a proxy which is changing
: your data... refusing connection.." over the past 3 days.

This would be a lot better if it came with logs, bug reports, and data.
It could also be the destination site having problems, or the exit relay
is overloaded, or sun flares.  The Internet is complex, narrowing down
the problem to Tor or not Tor is a first step.

I have no idea how to log (privoxy or tor??) these, maybe you could explain how its done, just in case they start happening again..

1. Connection Disconnected:

The browser has a little message "connection closed" on a white background (not a privoxy message).

If the server (or proxy) accepts the connection but closes
it without sending any data, Privoxy versions before 3.0.7
will send the text 'Connection: close' to the client.

This bug was fixed more than three years ago and is yet
another reason why you might want to consider updating
your Privoxy version.

Nowadays you get a proper problem description:

|fk@r500 ~ $lynx --dump
|   502
|       This is [1]Privoxy 3.0.17 on Privoxy-Jail.local (, port 8118,
|       enabled
|   Warning:
|      This Privoxy version is based on UNRELEASED code and not intended for
|      production systems!
|      Use at your own risk. See the [2]license for details.
|   No server or forwarder data received
|      Your request for [3] could not be
|      fulfilled, because the connection to ( has been
|      closed before Privoxy received any data for this request.
|      This is often a temporary failure, so you might just [4]try again.
|      If you get this message very often, consider disabling
|      [5]connection-sharing (which should be off by default). If that doesn't
|      help, you may have to additionally disable support for connection
|      keep-alive by setting [6]keep-alive-timeout to 0.

It's still a frequent "problem" when using Tor. Yesterday it happened
for around 1% of my requests (some of them were made without Tor, though):

fk@r500 ~ $privoxy-log-parser --statistics /usr/jails/privoxy-jail/var/log/privoxy/privoxy.log.1
Client requests total: 7881
Crunches: 1100 (13.96%)
Outgoing requests: 6781 (86.04%)
Server keep-alive offers: 2802 (35.55%)
New outgoing connections: 5535 (70.23%)
Reused connections: 1246 (15.81%)
Empty responses: 95 (1.21%)
Empty responses on new connections: 1 (0.01%)
Empty responses on reused connections: 94 (1.19%)
Method distribution:
7052 : GET 753 : CONNECT 46 : POST Client HTTP versions:
7830 : HTTP/1.1
21 : HTTP/1.0
URL statistics are disabled. Increase --url-statistics-threshold to enable them.

Note that it isn't necessarily caused by the exit node itself,
it can also happen simply because the server closed the connection
but the Tor client hasn't noticed it yet and thus still accepts
data on an already-dead connection. This would explain the number
of "Empty responses on reused connections".

Yes Fabian I would think that ordinarily the failure to connect does occur about this frequent, it used to happen very frequently when lots of chinese exits were on-line.

But thats not what I saw in the case of this - what I saw was (very nearly - over 3 days) 100% failure (after the 1st day), on all circuits re-used or new on about 50+ attempts (some 20+ on new circuits, after I started closing the failed ones in an attempt to kick the system into proper use). Also, as I said most failed access circuits still survived.

I'll have a look using v3.0.16, but I'm not expecting any errors now that the access has been fixed.

To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/