[tor-dev] BOINC-based Tor wrapper

[Yawning Angel]

On Wed, 22 Jul 2015 01:06:41 +1000
teor <teor2345 at gmail.com> wrote:

> 
> > On 20 Jul 2015, at 11:11 , Serg <std.serg at gmail.com> wrote:
> > 
> >> How do you plan to map ports on NAT devices?
> > 
> > If it can't be done automatically using UPnP, This must be done
> > manually. No alternative cases.
> 
> Our experience is that most routers' UPnP / NAT-PMP implementations
> don't work well with (our) automated tools. So this would have to be
> done manually, significantly reducing the pool of available
> volunteers.

Just chiming in here.  This may well work for a good number of users,
but the support overhead for when it fails is utterly gigantic because
certain brands of consumer routers have extremely poor UPnP/NAT-PMP
implementations.

The usual symptom of a poor implementation is "the router crashes" but
certain other behaviors have been documented in the past by people
trying to use UPnP in ways that are spec compliant such as "the router
crashes and requires a NVRAM reset", "random port mappings get
obliterated", "the UPnP/NAT-PMP stack on the router crashes" etc.

A bigger issue is that a lot of consumer grade routers have a very
limited amount of NAT session tracking space (in terms of absolute
number of connections), which makes machines behind such devices
extremely poor Tor relays (and even worse Guards)[0].

-- 
Yawning Angel

[0]: In an ideal world every relay should be able to handle having a TCP
connection open to any other relay simultaneously, plus connections from
clients if they are guards, since relays do not get to choose their
peers. Relays that fail to meet this criteria are (IMO) harmful to the
health of the network.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150721/4c74c5ba/attachment.sig>