With the following enabled, UPNP should not attempt to open a port at the router for 8333, however in the latest stable the port is uselessly opened. At best it's doing nothing productive, at worst it's just advertising the existence of a bitcoin client.
onlynet=tor
tor=127.0.0.1:9050
discover=0
listen=0
Compiling with USE_UPNP=- works as a temporary solution, but is by no means ideal.
If using Bitcoin-Qt make sure to unset the UPnP option. For using bitcoind, I'm looking into a little patch currently.
As far as I can see, -listen=0 should already disable UPnP by default. Only if you enable it explicitly through -upnp (or upnp=1), or the GUI should it be enabled. If that's not the case, it's a bug.
My reasoning would be that the bind=XXX re-enables listen, and hence upnp is not disabled.
Edit: does it work if you explicitly add upnp=0 to the config?
If you explicitly set listen to false, bind shouldn't re-enable it.
Guess this needs to be fixed before 0.9 as well.
Would this suffice (change in net.cpp)?
<pre> // only map ports when not using Tor if (!IsLimited(NET_TOR)) // Map ports with UPnP MapPort(GetBoolArg("-upnp", fDefaultUpnp)); </pre>
We already have in init.cpp the check for listen:
<pre> if (!GetBoolArg("-listen", true)) { // do not map ports or try to retrieve public IP when not listening (pointless) SoftSetBoolArg("-upnp", false); SoftSetBoolArg("-discover", false); } </pre>
Your change would make it impossible to map ports when using Tor.
The goal is to make the default (if not overridden using -upnp) to not map ports when using Tor, not to make it completely impossible.
I'm out... too many cases to consider for my ill brain ^^.
This appears to have been already solved:
if (!GetBoolArg("-listen", true)) {
// do not map ports or try to retrieve public IP when not listening (pointless)
if (SoftSetBoolArg("-upnp", false))
...