Opened 7 years ago

Closed 6 years ago

#2264 closed defect (fixed)

Dynamically choose available Tor ports in Tor Browser Bundle

Reported by: Sebastian Owned by: erinn
Priority: High Milestone: TorBrowserBundle 2.2.x-stable
Component: Applications/Tor bundles/installation Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

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.


Child Tickets

TicketStatusOwnerSummaryComponent
#2843closedmikeperryCheck an environment variable for a SOCKS portTorBrowserButton
#3076closedImplement 'SocksPort auto' and 'ControlPort auto'Core Tor/Tor
#3077closedchiiphVidalia needs to obtain SocksPort and ControlPort from torArchived/Vidalia

Change History (15)

comment:1 Changed 7 years ago by Sebastian

Component: - Select a componentTor bundles/installation
Owner: set to erinn

comment:2 Changed 7 years ago by mikeperry

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.

comment:3 Changed 7 years ago by mikeperry

I created ticket #2843 for the torbutton env variable.

comment:4 Changed 7 years ago by mikeperry

Parent ID: #2880

comment:5 Changed 7 years ago by mikeperry

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

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.

comment:6 Changed 7 years ago by mikeperry

Summary: Dynamically chose available Tor ports in Tor Browser BundleDynamically choose 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.

comment:7 Changed 7 years ago by erinn

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.

comment:8 Changed 7 years ago by 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.

comment:9 in reply to:  8 Changed 7 years ago by mikeperry

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...

comment:10 Changed 7 years ago by erinn

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

comment:11 Changed 6 years ago by mikeperry

Description: modified (diff)

comment:12 Changed 6 years ago by erinn

Milestone: TorBrowserBundle 2.2.x-stable

comment:13 Changed 6 years ago by mikeperry

Parent ID: #2880

comment:14 Changed 6 years ago by mikeperry

Priority: normalmajor

comment:15 Changed 6 years ago by erinn

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.