AdvTor

Anon Mus my.green.lantern at googlemail.com
Sat Oct 9 15:35:57 UTC 2010


Fabian Keil wrote:
> Anon Mus <my.green.lantern at googlemail.com> wrote:
>
>   
>> andrew at torproject.org wrote:
>>     
>>> On Thu, Oct 07, 2010 at 05:20:08PM +0100, my.green.lantern at googlemail.com 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 at r500 ~ $lynx --dump http://10.0.0.1/empty-response
> |   502
> |
> |       This is [1]Privoxy 3.0.17 on Privoxy-Jail.local (10.0.0.1), 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]http://10.0.0.1/empty-response could not be
> |      fulfilled, because the connection to 10.0.0.1 (10.0.0.1) 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 at 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".
>
> Fabian
>   
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 at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/



More information about the tor-talk mailing list