[tor-dev] Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
nickm at torproject.org
Tue Jul 21 15:38:00 UTC 2015
Yawning's mail below reminds me: I am considering removing the C
implementation of tor-fw-helper from the tor distribution, and recommending
Yawning's pure-Go implementation instead. But before I do this, I'd like
to get some sense of whether folks are shipping tor-fw-helper today, or
using it in practice.
On Jul 21, 2015 11:26 AM, "Yawning Angel" <yawning at schwanenlied.me> wrote:
> 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
> 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.
I wonder how commercial software handles these cruddy routers. Do they
restrict themselves to a tiny part of the spec? Do they probe for
problematic firmware, and maintain a list of unreliable versions?
[I am very glad it is not our job to maintain such a list.]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tor-dev