Re: frequent empty/closed connections
Scott Bennett benn...@cs.niu.edu wrote: On Mon, 03 Aug 2009 09:21:53 -0400 The Doctor dr...@virtadpt.net wrote: Scott Bennett wrote: Empty server or forwarder response. The connection has been closed but Privoxy didn't receive any data. ... Does anyone else get these, too? I suspect that the problem may be in privoxy, rather than tor, but haven't yet figured out a test for that hypothesis. Any ideas? If the keep-alive-timeout directive is used, Privoxy versions before 3.0.14 beta don't take the latency into account and may try to reuse a connection that has already been closed on the server side but still appears to be open from the point of view of the client. The result is the error message you mention above. I've been seeing this behavior off and on for a few months now, but not so often that I felt like tracking it down. Generally, I just reload the page and everything's fine. Sometimes it takes several reload attempts to get it to work, though. It also thoroughly bollixes automatically refreshed pages like the small GOES East images I like to keep handy and updated to most recent half hour. Any other automated accesses, such as through curl, wget, et al. are also screwed when it happens. If someone has an idea of how to prove that the problem is in privoxy and not in tor, I can try to file a bug report there. To really prove anything, you'd have to watch the server side as well, without that you can still make assumptions, though. If you enable connection debugging in Privoxy, you can tell from the log messages whether or not the problem happened while reusing a connections. If it only happens while reusing a connection it likely is a Privoxy problem. Otherwise it most likely isn't. If the problem goes away after disabling the keep-alive-timeout directive, and reappears right after enabling it again, that would indicate a Privoxy problem as well. If you report a problem for Privoxy 3.0.12, the first response will be Please try to reproduce it with 3.0.14 beta, so you probably want to upgrade before looking into this. A FreeBSD port skeleton is available on the SF project page. Fabian signature.asc Description: PGP signature
Re: Which proxy to use?
Mr. Blue trashd...@yahoo.com wrote: - Original Message - From: coderman coder...@gmail.com On Sat, Aug 1, 2009 at 9:19 AM, Mr. Bluetrashd...@yahoo.com wrote: 2) Must be capable to run as a reverse proxy. what are you trying to do, exactly? I wana have ONE proxy app installed Well, curently, I am using privoxy, which achieves a) exit notattion striping, but it can not act as a b) reverse proxy. What's your definition of reverse proxy? If you simply want the proxy to process intercepted requests, you may want to have a look at Privoxy's accept-intercepted-requests directive. Fabian signature.asc Description: PGP signature
[Fwd: Tor 0.2.1.18 and 0.2.1.19 are released]
For those who didn't see the announcement, we have a new stable release
based on the 0.2.1.x codebase.
Original Message
Subject: Tor 0.2.1.18 and 0.2.1.19 are released
Date: Thu, 6 Aug 2009 01:51:12 -0400
From: Roger Dingledine a...@mit.edu
To: or-annou...@torproject.org
Tor 0.2.1.18 lays the foundations for performance improvements, adds
status events to help users diagnose bootstrap problems, adds optional
authentication/authorization for hidden services, fixes a variety of
potential anonymity problems, and includes a huge pile of other features
and bug fixes.
Tor 0.2.1.19 fixes a major bug with accessing and providing hidden
services.
https://www.torproject.org/easy-download
Changes in version 0.2.1.19 - 2009-07-28
o Major bugfixes:
- Make accessing hidden services on 0.2.1.x work right again.
Bugfix on 0.2.1.3-alpha; workaround for bug 1038. Diagnosis and
part of patch provided by optimist.
o Minor features:
- When a relay/bridge is writing out its identity key fingerprint to
the fingerprint file and to its logs, write it without spaces. Now
it will look like the fingerprints in our bridges documentation,
and confuse fewer users.
o Minor bugfixes:
- Relays no longer publish a new server descriptor if they change
their MaxAdvertisedBandwidth config option but it doesn't end up
changing their advertised bandwidth numbers. Bugfix on 0.2.0.28-rc;
fixes bug 1026. Patch from Sebastian.
- Avoid leaking memory every time we get a create cell but we have
so many already queued that we refuse it. Bugfix on 0.2.0.19-alpha;
fixes bug 1034. Reported by BarkerJr.
Changes in version 0.2.1.18 - 2009-07-24
o Major features (clients):
- Start sending bootstrap phase status events to the controller,
so it can keep the user informed of progress fetching directory
information and establishing circuits. Also inform the controller
if we think we're stuck at a particular bootstrap phase. Implements
proposal 137.
- Clients replace entry guards that were chosen more than a few months
ago. This change should significantly improve client performance,
especially once more people upgrade, since relays that have been
a guard for a long time are currently overloaded.
- Network status consensus documents and votes now contain bandwidth
information for each relay. Clients use the bandwidth values
in the consensus, rather than the bandwidth values in each
relay descriptor. This approach opens the door to more accurate
bandwidth estimates once the directory authorities start doing
active measurements. Implements part of proposal 141.
o Major features (relays):
- Disable and refactor some debugging checks that forced a linear scan
over the whole server-side DNS cache. These accounted for over 50%
of CPU time on a relatively busy exit node's gprof profile. Also,
disable some debugging checks that appeared in exit node profile
data. Found by Jacob.
- New DirPortFrontPage option that takes an html file and publishes
it as / on the DirPort. Now relay operators can provide a
disclaimer without needing to set up a separate webserver. There's
a sample disclaimer in contrib/tor-exit-notice.html.
o Major features (hidden services):
- Make it possible to build hidden services that only certain clients
are allowed to connect to. This is enforced at several points,
so that unauthorized clients are unable to send INTRODUCE cells
to the service, or even (depending on the type of authentication)
to learn introduction points. This feature raises the bar for
certain kinds of active attacks against hidden services. Design
and code by Karsten Loesing. Implements proposal 121.
- Relays now store and serve v2 hidden service descriptors by default,
i.e., the new default value for HidServDirectoryV2 is 1. This is
the last step in proposal 114, which aims to make hidden service
lookups more reliable.
o Major features (path selection):
- ExitNodes and Exclude*Nodes config options now allow you to restrict
by country code ({US}) or IP address or address pattern
(255.128.0.0/16). Patch from Robert Hogan. It still needs some
refinement to decide what config options should take priority if
you ask to both use a particular node and exclude it.
o Major features (misc):
- When building a consensus, do not include routers that are down.
This cuts down 30% to 40% on consensus size. Implements proposal
138.
- New TestingTorNetwork config option to allow adjustment of
previously constant values that could slow bootstrapping. Implements
proposal 135. Patch from Karsten.
- Convert many internal address representations to optionally hold
IPv6 addresses. Generate and accept IPv6 addresses in
Re: Tor on iPhone / iPod touch
On 08/03/2009 01:11 PM, Michael Gomboc wrote: I would like to use tor with my iPod touch 1g OS 3. I found one project on that: http://wickedpsyched.net/nettools But that doesn't work on the OS 3. Someone knows about IPhone developing or have heard about someone who did the compiling? A few people have managed to get Tor working on the iphone. Right now, you have to jailbreak your phone to get Tor on it. However, we are working on seeing how to get Tor onto phones without requiring the phone to be jailbroken, and possibly via the App Store. As of tor 0.2.0.30, configure supports --enable-iphone option. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
Re: Thanks for the inclusion...
On 07/31/2009 03:37 PM, Michael Cozzi wrote: I've been considering writing a guide or white paper on how to use Tor as an IT professional. May I submit it? By all means, please do so. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identica/Twitter: torproject
