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 [email protected] > > 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
