[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Setting up a private tor network
Karsten Loesing wrote:
I've seen the long delays in the clients (running as Tor proxy nodes)
before they were able to build
circuits. Smaller (but still huge) delays in the routers, and some
delays in the authoritative directories.
What surprised me, however, is how casual the behavior is. Is there some
casualty intentionally in
the protocol? Or is it just the result of concurrence between the nodes
that we start up almost
simultaneously? I don't know yet but it was e.g. strange to see how the
three routers I was starting
-----BEGIN PGP SIGNED MESSAGE-----
I have seen similar error and warning messages to what you have
mentioned, both with 0.1.2.17 and with 0.2.0.8-alpha.
Quoting from your private mail (with your permission):
I've seen in your doc that you are killing and restarting Tor
instances in order to have the thing running. I have also seen a note
on that, but till now I was trying to avoid that, I was hoping that
there is a combination of configurations with which things start up
smoothly. Before I go into the restart game, I would like to be sure
if my torrc files are good or not.
In PuppeTor I did not get 0.2.0.8-alpha to work in a private network
setting, but only versions up to 0.2.0.7-alpha. Further, the current
trunk (or what will become 0.2.0.9-alpha these days) introduces the new
v3 directories that make things a little bit more complicated:
The solution for building a private network with all versions up to
0.2.0.7-alpha is to periodically send HUP signals to the nodes until
they start building circuits. In principal you don't have to, but it
accelerates things a lot; as an example, I tried to create a private
network with 2 directories and 4 routers _without_ sending HUP commands:
3 out of 10 attempts built circuits after 15 minutes and a few seconds,
and the other 7 attempts took 60 minutes and a few seconds for it. The
multiples of 15 minutes should come from the interval in which directory
mirrors fetch networkstatuses from the directory authorities. When
sending HUP signals, the whole process takes about half a minute. The
reason is that directory mirrors refetch the networkstatus immediately
when reloading their configuration. As a side note: proxies behave
differently for this. If you want to read more, have a look at the
Javadocs of PuppeTor's ProxyNode class:
up behaved differently.
After seeing your comments on difficulties with v3, I have decided to
postpone experiments with
0.2.0.8-alpha. I'm concentrating on stabilizing the environment at the
moment. Then I think we might
In 0.2.0.8-alpha-dev (and newer versions) you need to configure v3
directory authorities to get things working. There is a description how
to do this here:
In order to speed up the process you can configure Tor to build
consensuses in shorter intervals. The following configuration worked for
me: V3AuthVotingInterval 10 minutes, V3AuthVoteDelay 1 minute,
V3AuthDistDelay 1 minute. Unfortunately, the process still takes about
half an hour, so this is only a first solution to get it working. If you
find a better solution, please let us know!
use the two environments to cross-check results.
I see your point, and I have to say I had similar reasons to go for a
low-level emulation approach.
First of all, I was more interested in Tor performance at the
transmission level. Here, especially if
thinking of using datagrams instead of TCP tunnels, packet level capture
and more control over the
After seeing PuppeTor I've realized that mine is quite similar to it
in its goals, [...]
First of all, it's good to have multiple approaches to this problem. We
could both learn from the other approach and improve our tools.
My decision to not use a virtual machine for each node was that I did
not see why it should be necessary. In PuppeTor every Tor node has it's
own working directory and set of ports and should not interfere with the
other local Tor processes. The only output that I care about is what Tor
writes to its log files. My primary motivation for writing PuppeTor was
to test my developments on Tor hidden services which are rather
high-level in Tor.
However, when it comes to lower levels, like sniffing or altering
packets, my approach might be too limited. I'm not sure about that,
because I rarely used that. Thus, there is room for other approaches! :)
network environment helps.
I did not study the logging part of the code, but when I see a packet
flying on the net, I know there was
communications, and when there is none, I know there wasn't. Logging
(which, btw, is very nice and
extensive in Tor) gives an explanation of what the developer thinks
about the event, or about the cause,
but it could be misleading. It was also not explaining me the problems I
had with DNS during the setup
of the private Tor network, while the sniffer showed what is happening.