Please test these experimental bundles that have tor-fw-helper included. You may know that flash proxy requires people to set up port forwarding (https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto). tor-fw-helper is a tool that uses UPnP or NAT-PMP to forward a port automatically. I'm interested in finding out how likely it is to work.
https://people.torproject.org/~dcf/pt-bundle/3.5.2-fwhelper-1/
The bundles are configured to run flash proxy and tor-fw-helper. You just have to click "Connect" and wait up to 60 seconds. You don't have to do any special tests; just see whether it bootstraps or not.
If you want to see more of what's going on, look at the file flashproxy-client.log that will be created inside the bundle. When tor-fw-helper fails, it looks like this:
2014-02-09 01:15:52 Running port forwarding command: ./tor-fw-helper -p 49334:49334 2014-02-09 01:16:00 tor-fw-helper: tor-fw-helper tcp-forward 49334 49334 FAIL All port forwarding backends (natpmp) failed. 2014-02-09 01:16:00 tor-fw-helper: E: upnpDiscover returned: NULL 2014-02-09 01:16:00 tor-fw-helper: V: natpmp initialized... 2014-02-09 01:16:00 tor-fw-helper: tor-fw-helper: 1 NAT traversal helper(s) loaded 2014-02-09 01:16:00 tor-fw-helper: E: readnatpmpresponseorretry failed -7 2014-02-09 01:16:00 tor-fw-helper: E: errno=61 'Connection refused' 2014-02-09 01:16:00 tor-fw-helper: E: NAT-PMP It appears that something went wrong: -7 2014-02-09 01:16:00 tor-fw-helper: tor-fw-helper: tor_fw_add_port backend natpmp returned: -7 2014-02-09 01:16:00 tor-fw-helper exited with status 1.
This is the branch from which the bundles are built. The second link shows what's different in the branch relative to the TBB 3.5.2 release.
https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/... https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/3.5...
David Fifield
David Fifield:
Please test these experimental bundles that have tor-fw-helper included. You may know that flash proxy requires people to set up port forwarding (https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto). tor-fw-helper is a tool that uses UPnP or NAT-PMP to forward a port automatically. I'm interested in finding out how likely it is to work.
https://people.torproject.org/~dcf/pt-bundle/3.5.2-fwhelper-1/
The bundles are configured to run flash proxy and tor-fw-helper. You just have to click "Connect" and wait up to 60 seconds. You don't have to do any special tests; just see whether it bootstraps or not.
I've tried on a Ubuntu 13.10 live system one one network. No luck. :(
The log says “tor-fw-helper: tcp-forward 37482 37482 SUCCESS miniupnp”, exit with status 2. flashproxy-reg-http says “Registered”… but Tor does not bootstrap.
Lunar:
David Fifield:
Please test these experimental bundles that have tor-fw-helper included. You may know that flash proxy requires people to set up port forwarding (https://trac.torproject.org/projects/tor/wiki/FlashProxyHowto). tor-fw-helper is a tool that uses UPnP or NAT-PMP to forward a port automatically. I'm interested in finding out how likely it is to work.
https://people.torproject.org/~dcf/pt-bundle/3.5.2-fwhelper-1/
The bundles are configured to run flash proxy and tor-fw-helper. You just have to click "Connect" and wait up to 60 seconds. You don't have to do any special tests; just see whether it bootstraps or not.
I've tried on a Ubuntu 13.10 live system one one network. No luck. :(
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.
Two other problems I can think of:
* 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. * 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.
Otherwise, I think it's pretty awesome to be that straightforward to use.
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
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”.
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
(Devs are in Iceland, post bundles.)
Here are revised bundles in response to some of the problems we've seen so far (thanks especially to Lunar).
https://people.torproject.org/~dcf/pt-bundle/3.5.2-fwhelper-2/
The changes relative to 3.5.2-fwhelper-1: * NAT-PMP is completely disabled and removed. it didn't seem to be working (maybe it is only for Apple routers), and we saw one of libnatpmp's programs segfault (though not tor-fw-helper itself). https://trac.torproject.org/projects/tor/ticket/5213#comment:14 * The client is forced to use IPv4 with the -4 option. Though flashproxy-client supports IPv6, and IPv6 can sometimes work to get around NAT, tor-fw-helper only does IPv4 port forwardings, and that's what we're trying to test. We encountered a problem where the external IPv6 address was being registered, rather than the IPv4 address that was forwarded. * Uses a static port 9000 for the external listener, instead of an ephemeral port. This is to make it easier for testers to clean up their port forwarding table, because tor-fw-helper appears to leave the forwardings active. https://lists.torproject.org/pipermail/tor-qa/2014-February/000335.html
Like before, you just have to click "Connect" and wait up to 60 seconds. You don't have to do any special tests; just see whether it bootstraps or not.
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.
Changes relative to master: https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/3.5... Changes relative to 3.5.2-fwhelper-1: https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/3.5...
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
-
David Fifield -
Lunar -
Roger Dingledine