On Wed, 22 Jul 2015 01:06:41 +1000 teor <teor2345@xxxxxxxxx> wrote: > > > On 20 Jul 2015, at 11:11 , Serg <std.serg@xxxxxxxxx> 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.
Attachment:
pgpToKk_VavJk.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev