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@schwanenlied.me> wrote:
>
> On Wed, 22 Jul 2015 01:06:41 +1000
> teor <teor2345@gmail.com> wrote:
>
> >
> > > On 20 Jul 2015, at 11:11 , Serg <std.serg@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.

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

--
Nick