On Thu, Apr 21, 2011 at 9:26 AM, Jacob Appelbaum <[email protected]> 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 [email protected] 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
