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

[Daniel Bryg]

Sorry for jumping in late, see my comments below.

On Thu, Apr 21, 2011 at 9:26 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> On 04/19/2011 03:17 AM, Runa A. Sandvik wrote:
>> 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.

Buffalo with a 1Gb USB flash works as a bridge/client but the bridge
is not very busy so I don't know what the limits are. See my stats
I've just posted to #2334. I don't really see a quick solution that
would work without adding extra storage. Fortunately, the flash drives
can be small and barely visible. But one thing that must be improved
here is formatting it with a usb-friendly filesystem as I'm using ext2
which was the easiest to install.

>> #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

I believe the only files that can stay unchanged over router's
lifetime is secret_id_key in (the fingerprint file is recalculated
from it on each start). In my patch I moved this one file to /etc/tor.
Should I be worried about getting new descriptors on each reboot which
hopefully happens only once every few weeks?

>> #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.

I can package it that way and then you can submit. As discussed in
#2370, I'm of opinion that once we have a mature release, the UI
should be made into a separate package. Vidalia is separate on other
linux systems, and this situation is similar. Maybe the Luci guys
should express themselves on that as i think they maintain all of the
UI code, but i may be wrong.

>> #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.

I agree but if you want something corny: RoutOr - there's no Tor in it ;)

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

If we're including the UI in the package, and the UI uses geoip should
we include geoipdb as well?

>> 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.

My current package enables both by default. Easy to change.

>> 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.

There are a few things there that I'm not entirely happy and I am
planning to work on them. The config situation should be clarified,
for example. I'll get back to you on this.

All in all, I know I'll be working on this project so I can take the
responsibility of creating packages once it's been decided what goes
in to what repo and such. I could probably help with a build machine,
too.

Cheers,
Daniel