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

Re: Setting up a private tor network

Karsten Loesing wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Csaba,
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:
https://tor-svn.freehaven.net/svn/puppetor/trunk/src/de/uniba/wiai/lspi/puppetor/ProxyNode.java
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 
up behaved differently.


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:
https://tor-svn.freehaven.net/svn/tor/trunk/doc/v3-authority-howto.txt .
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!
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 
use the two environments to cross-check results.

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

Csaba