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

["Runa A. Sandvik" <runa.sandvik@xxxxxxxxx>]

On Thu, Apr 21, 2011 at 9:26 AM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> wrote:
> 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.

As far as I know, the router can handle being a bridge as long as it
has enough disk space.

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

Great.

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

I don't think we should ship our own image, for the simple reason that
we already have enough stuff to maintain.

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

Ok, do you want to take care of this? That is, putting the web
interface into version control and packaging it for OpenWrt.

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

Sure, that works too.

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

So, it turns out that packages in OpenWrt are not updated after a
release. That explains why I got 0.2.1.26 when 0.2.1.30 is available
in the OpenWrt SVN.

The best way to ensure that users can easily upgrade Tor and related
packages is to set up a torproject.org repository for OpenWrt
packages. This repository would then have to be added to
/etc/opkg.conf.

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

Sounds good.

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

Is this something you can / want to take care of?

-- 
Runa A. Sandvik
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev