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