Dynamically choose available Tor ports in Tor Browser Bundle

We're only doing a printf "Tor is already running, please stop that" which doesn't help gui users. The real solution is dynamically picking available ports and altering the configuration accordingly.

[[TicketQuery(parent=#2264 (closed),format=table,col=component|owner|summary|priority|points,order=priority)]]

changed milestone to %TorBrowserBundle 2.2.x-stable

added component::applications/tor bundles/installation milestone::TorBrowserBundle 2.2.x-stable owner::erinn priority::high resolution::fixed status::closed type::defect labels

Trac:
Owner: N/A to erinn
Component: - Select a component to Tor bundles/installation

For torbutton's part, it is very easy for me to inspect an environment variable for an alternate port. I can hack this in whenever you like. It should be easier than you mucking with prefs.js.

Trac:
Actualpoints: N/A to N/A
Points: N/A to N/A

I created ticket #2843 (closed) for the torbutton env variable.

Trac:
Parent: N/A to #2880 (closed)

I think the dynamic port choice is the way to go here for all platforms. In the rare event that a user has a bittorrent client or something else listening on a Tor Port, any sort of error message is the wrong way to go, I think. We should just solve the root problem so there does not need to be any cryptic error messages.

Trac:
Summary: Linux TBB users don't get a useful error msg when Tor is running to Dynamically chose available Tor ports in Tor Browser Bundle

Might as well try to spell at least a couple words right here and there.

Further comment: I recall back in the day when upgrading between different bundle types on Windows and Mac OS that some users would end up with a stray tor or privoxy process running, breaking the new bundle. If we mess that up, that is obviously a bug. But there should be no reason to burden the user to clean up after us in that case, either. We should just choose a new port and leave the old thing running.

Trac:
Summary: Dynamically chose available Tor ports in Tor Browser Bundle to Dynamically choose available Tor ports in Tor Browser Bundle

I agree with the dynamic port idea. What's going to be the best way for it to be done, across platforms? With the Linux and OS X TBBs it'd be pretty "easy" since the launch script is just a shell script, but there's probably a smarter way to do it and I have absolutely no idea (right now) how to do it on Windows.

But before we figure that out: should it be up to the launch script to look and see what ports are open, and then somehow choose the smartest one, or is there a better / less hacky way to do this, possibly within Tor or Vidalia?

The benefit of dropping Polipo is that we don't have to configure its port anymore.

Tor could dynamically choose one, e.g. 'socksport auto'. It would poke around until it finds something it can bind.

Same with controlport, I guess.

The trick then would be: how do we tell the caller which port we picked? Can't use the controlport, clearly. Parsing logs on stdout is an option, but kind of klunky.

And then the question becomes: who does that parsing? Vidalia comes to mind, since it will want to know the answer anyway in order to tell Firefox (and thus Torbutton) when it launches them, and in order to display them in the GUI.

Replying to arma:

Tor could dynamically choose one, e.g. 'socksport auto'. It would poke around until it finds something it can bind.

Same with controlport, I guess.

The trick then would be: how do we tell the caller which port we picked? Can't use the controlport, clearly. Parsing logs on stdout is an option, but kind of klunky.

And then the question becomes: who does that parsing? Vidalia comes to mind, since it will want to know the answer anyway in order to tell Firefox (and thus Torbutton) when it launches them, and in order to display them in the GUI.

I think we should just run with this. Shall I create two child tickets, one for Tor (SocksPort Auto) and one for Vidalia to parse the logs?

Otherwise we'll block forever on the perfect solution that just isn't going to happen, like a named pipe control port interface...

Since nobody else said yes, I'm going to say: yes, please do that.

Trac:
Description: We're only doing a printf "Tor is already running, please stop that" which doesn't help gui users. I'm not sure what the real solution is short of dynamically picking available ports and altering the configuration

to

We're only doing a printf "Tor is already running, please stop that" which doesn't help gui users. The real solution is dynamically picking available ports and altering the configuration accordingly.

[[TicketQuery(parent=#2264 (closed),format=table,col=component|owner|summary|priority|points,order=priority)]]

Trac:
Milestone: N/A to TorBrowserBundle 2.2.x-stable

Trac:
Parent: #2880 (closed) to N/A

Trac:
Priority: normal to major

This works as of release 2.2.32-1 on all platforms.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed

mentioned in issue #2547 (closed)

mentioned in issue #2843 (closed)

mentioned in issue #3076 (moved)

mentioned in issue #3077 (closed)

mentioned in issue #3659 (closed)

mentioned in issue #3843 (closed)

mentioned in issue tpo/core/tor#3076 (closed)