[tor-dev] The Torouter project - where are we now?

[Jacob Appelbaum]

On 04/19/2011 03:17 AM, Runa A. Sandvik wrote:
> Hi everyone,
> 
> I am trying to figure out how we can move the Torouter project
> forward. In this email, I will try to summarize the current status of
> this project.
> 
> The Torouter project has a total of four bugs in Trac. These are
> #2334, #2376, #2370 and #2596.
> 
> #2334: Torouter on Buffalo breaks with large cached-descriptors[.new]
> files. The quick and easy solution here is to attach a USB stick to
> the router and use it as Tor's data directory. However, it would be
> great if someone could take a look at this and figure out a way to
> solve it.

This is only a problem on smaller hardware - so if we really want the
Buffalo router, we'll need to fix this or create a work around that
isn't a total PITA. For now, I think we can just add a USB disk and deal
with it later.

If we find that the router can't handle being a bridge, I'm not really
concerned with this bug.

> 
> #2376: Torouter on OpenWrt shouldn't have its data directory in /tmp/.
> The problem with having Tor's data directory in /tmp is that whenever
> Torouter is rebooted, Tor generates new keys and gets a new
> fingerprint.

I commented on the bug - it's easy enough to change this by submitting a
patch to openwrt-devel at lists.openwrt.org


> 
> There are a couple of different ways to solve this problem; Karsten
> suggested that we could modify OpenWrt to stop creating a /tmp
> partition. This probably means that we will have to ship our own
> OpenWrt image. I'm thinking that another option would be to modify the
> Tor-OpenWrt-package to use / as the data directory instead of /tmp.
> However, I wonder if 64M (no matter how it's partitioned) of space on
> the Buffalo router is insufficient as long as #2334 remains open.

If we're shipping our own image, we can do a bunch of stuff. Is that
what we want to do?

> 
> #2370: Torouter basic Web UI for OpenWrt. I haven't tried the web
> interface myself, but development seems to be moving along nicely. I'm
> not sure what the remaining steps are, other than packaging it as
> tor-ui (or similar) for OpenWrt.
> 

The web interface should go into version control, it should be added to
the tor-alpha package in the OpenWRT svn (that's why I created it), and
it should be used by some people.

> #2596: Figure out a better name than "torouter". Andrew thinks we
> should come up with a better name for this project, one that does not
> have "Tor" in the name. Suggestions?
> 

I think torouter is a perfectly fine name until we actually have a
shipping prototype.

> The Torouter project also has some open questions (some are mentioned
> on https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/Torouter
> as well):
> 
> 1. How can we make sure that the version of Tor in OpenWrt is always
> up to date? Should we set up our own OpenWrt repository? Right now,
> the version of Tor in OpenWrt is 0.2.1.26. Also, should we offer
> packages for both stable and unstable?

I think we should contribute back to OpenWRT (as I've been doing) and
for our router, we should consider adding a feed for the specific
hardware we intend to support. Still, we'll need to ensure the versions
of _everything_ are up to date and not just Tor.

So what's our general update strategy for any platform we ship?

> 
> 2. We want to collect statistics, which means that we need to ship a
> GeoIP file as well. I'm thinking we should create a tor-geoipdb
> package for OpenWrt. Thoughts?
> 

There's a tor-geoip package created by the tor package in the OpenWRT
svn repo (from looking at the Makefile).

> 3. Do we want one Tor process for bridging and one for the transparent
> wifi network? I think this sounds good, if the router can handle it.
> If not, then just running a bridge is ok too.

I think we should run both in a single Tor for now but I think we should
only enable the bridge by default. The web UI can enable the transparent
stuff if we want it.

> 
> Have I missed anything important? Are there any other packages that we
> should include in OpenWrt? Other comments or suggestions? If you have
> more information or would like to help out, please let me know.
> 

We need to make packages for the libnatpmp and miniupnpc libraries
because we need tor-fw-helper support in tor-alpha.

All the best,
Jake