On Fri, Feb 14, 2014 at 09:37:51AM +0100, Lunar wrote:

We solved it with David. The problem was that the IPv6 address was given to registrators. Adding `-4` to the flashproxy-client flags in torrc made it work.

In the process, we discovered that NAT-PMP is having really weird behaviour and should probably be discarded.

I'm getting ready another set of bundles, without libnatpmp and with -4 by default.

* tor-fw-helper currently registers the port redirection under the label “Tor relay”. That's OK if used by a relay operator on their own network, but not in the use case where Tor is banned and you want to conceal its usage.

Good point. It's not configurable at runtime as tor-fw-helper is now.

* There's no unregistration process when the browser is shut down, so the ports will stay open as until the router is rebooted (or at least that was my impression). Probably we would like to fix that as browsers can be restarted several times in course of a single day.

Thank you for noticing this problem. I overlooked it because I assumed all the port forwardings were temporary; tor has code to call tor-fw-helper periodically. But you are right; in fact in libminiupnpc 1.5, the UPNP_AddPortMapping function doesn't even provide a way to set the time limit (NewLeaseDuration), and with libminiupnpc 1.6, tor-fw-helper always passes a value of 0 ("forever"). https://gitweb.torproject.org/tor.git/blob/745434d29a92da682f4c8d8fa70a56386... I configured flashproxy-client to listen on an emphemeral port in these bundles (in normal bundles it listens on the static port 9000). It means that a new permanent hole will be opened in the user's firewall every time they restart their browser. (Permanent until they reboot their router, I guess.) If you tested these bundles and now have unexpected port forwardings, you can (reboot your router or) run these commands from the miniupnpc package: upnpc -l # lists port forwardings upnpc -d X tcp # deletes forwarding for port X Alternatively, we could specify a static port (:9000 instead of :0 in the ClientTransportPlugin line). Then at least it would be just *one* port open permanently. But one of the nice things about automatic port forwarding was that it would be possible not to use a fixed (more easily blockable) port number. David Fifield

On Sat, Feb 15, 2014 at 08:35:06AM +0100, Lunar wrote:

David Fifield:

...

Alternatively, we could specify a static port (:9000 instead of :0 in the ClientTransportPlugin line). Then at least it would be just *one* port open permanently. But one of the nice things about automatic port forwarding was that it would be possible not to use a fixed (more easily blockable) port number.

That would prevent multiple users of the Flashproxy bundle on the same network. This makes some little yellow warning lights blink in my head. They are labelled “support headache ahead”.

That's a good point. Nevertheless I'm going to do another set of bundles with port 9000 set. That's because for now, I'm trying to judge the fraction of users for whom UPnP works at all, in order to see if it's worth working on more. Because of the difficulties we've found, it seems bundles with automatic port forwarding are at least several weeks away, if we do them at all. If we do such bundles, we must make sure they use ephemeral ports, and the port forwardings don't last forever. At least, I think tor-fw-helper should have a default timeout that is slightly longer than tor's default interval for calling it, and optionally should take an argument controlling how long the timeout should be. Ximin started looking at writing a replacement in a memory-safe language, which would dispel some of the concern about using a third-party C library (and incidentally work around the API compatibility between miniupnpc 1.5 and 1.6). David Fifield

On Sat, Feb 15, 2014 at 01:20:34PM -0800, David Fifield wrote:

* NAT-PMP is completely disabled and removed. it didn't seem to be working (maybe it is only for Apple routers)

That's correct -- pmp is Apple's version of upnp.

These bundles are still nothing close to a release candidate. We'll need to find a way to limit how long port forwarding lasts, at least, and make sure that the UPnP library is safe to deploy.

For a historical note, when we were first putting in this port-forwarding stuff, we had many problems with routers dropping our port forwarding request earlier than expected. That's how we settled on the "make it last forever and also re-request it every 15 minutes" (or whatever n is) that we do now. --Roger