Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#10500 closed defect (worksforme)

new torbutton says Tor is down when accessing remote 'tor' relay daemon

Reported by: starlight Owned by: brade
Priority: Medium Milestone:
Component: Applications/Tor Launcher Version:
Severity: Keywords:
Cc: mikeperry, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Torbutton as bundled with Linux TBB 3.5 sees Tor as down when configured with a remote 'tor' relay daemon and no control port access. FF works fine and this would not be a problem except that Torbutton seems to refuse to process cookies when in this state. Running previous Linux TBB 2.3.25-15 with Torbutton 1.5.2 and this problem is not apparent.

A guess is that the new Torbutton logic that takes over management of the 'tor' daemon from Vidalia is unhappy without the daemon running.

It should be possible to use a check-box, about:config setting or environment variable to enable Torbutton use with a remote system 'tor' daemon. For obvious reason this includes Torbutton accepting 'tor' as useable with no access to the 'tor' relay control port. In my case, an instance of Vidalia is run on a different system and the "new identity" function invoked from there at the same time "new identity" is invoked from Torbutton.

Configured this by issuing


and running


Then manually configuring the SOCKS proxy address.

I did look through the about:config extensions.torbutton for a setting for this and didn't see anything that looks like it.

Child Tickets

Attachments (2)

go_tff (306 bytes) - added by starlight 5 years ago.
script used to start TorFF
torbutton_diag.txt (11.7 KB) - added by starlight 5 years ago.
trace of successful TorButton/TorLauncher startup

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 years ago by gk

Cc: mikeperry added
Component: TorbuttonTor Launcher
Owner: set to brade
Version: Tor: unspecified

comment:2 Changed 5 years ago by mcs

Cc: mcs added

What happens if you set the hidden browser preference extensions.torlauncher.control_port to 0? That might trick Torbutton into *not* performing the local, control port based check that it uses to detect whether Tor is working.

comment:3 Changed 5 years ago by starlight

Tried that and it made no difference. Also tried setting

extensions.torlauncher.start_tor = false

and it didn't work either. In both cases I stopped
and restarted FF after making the change.

comment:4 Changed 5 years ago by starlight

Didn't realize Torlauncher was a separate plug-in till
it was mentioned in the follow-up. Tried disabling
Torlauncher while leaving Torbutton active but
that didn't work either.

comment:5 Changed 5 years ago by starlight

TBB 3.5.2

still a problem

comment:6 Changed 5 years ago by starlight

still a problem

Any hope for a fix or workaround?

TBB 3.6.1

comment:7 Changed 5 years ago by mcs

Today, Kathy Brade and I spent some time on this issue. Sorry for the delay.

Unfortunately, I do not think we were truly able to reproduce the problem you experienced. By tweaking preferences, we were always able to get things working correctly with a remote tor. We tested with TBB 3.6.2 (64-bit) on an Ubuntu 12.04 LTS system with a copy of tor running on another system. Here is a "clean slate" approach that we would like you to try:

1) Untar a new copy of TBB 3.6.2 into a new directory.
2) Before you start-tor-browser, create a file named tor_browser_en-US/Data/Browser/profile.default/prefs.js that contains lines similar to the following:

user_pref("extensions.torlauncher.control_port", 0);
user_pref("extensions.torlauncher.start_tor", false);
user_pref("extensions.torbutton.settings_method", "custom");
user_pref("extensions.torbutton.socks_host", "");
user_pref("extensions.torbutton.socks_port", 9050);
user_pref("network.proxy.socks", "");
user_pref("network.proxy.socks_port", 9050);

(adjust the SOCKS host and port to point to your tor).

Then start-tor-browser as usual.

If the about:tor page still shows an error and/or if Torbutton indicates that Tor is disabled, please use about:config to set the following preference values (or exit the browser and edit prefs.js):

browser.dom.window.dump.enabled true
extensions.torbutton.logmethod 0
extensions.torbutton.loglevel 0

Then restart your browser, copy the messages that are produced at the command line, and paste them into this bug report.

comment:8 Changed 5 years ago by starlight

Thank you for the help and information!

The config here didn't have the last two "network.proxy" lines
and port is 9150 instead of 9050, but I don't believe
this was an issue--made no difference.

However, I did find that when following the procedure
to produce the trace the TorButton icon magically
went green. Well not so magically. What appears to
have been the problem is I was starting my little
'go_tff' script (attached) from the "Run" dialog in
KDE rather than from a console window. So it appears
that whatever KDE does for stdin/stdout/stderr is
causing TorButton grief of some kind. Possibly this
should be addressed as it does not seem an unusual
idea to run directly from KDE.

I'm also attaching the trace output, though it
shows a successful start.

Once question I have now is that the "New Identity"
option on TorButton is greyed out. Am I stuck
stop/starting Firefox now? Before I would run
"New Identity" and then separately issue the
new identity action in the relay by invoking
"New Identity" from Vidalia running on a different
machine. I suppose I can put the FF run in a loop
so that it will restart immediately whenever exited.

Changed 5 years ago by starlight

Attachment: go_tff added

script used to start TorFF

Changed 5 years ago by starlight

Attachment: torbutton_diag.txt added

trace of successful TorButton/TorLauncher startup

comment:9 Changed 5 years ago by starlight

Hang on!!!

Scratch the second paragraph above.

Turns out what was different is that when capturing
the diagnostic trace I cut/pasted just the two
lines from 'go_tff' for changing the directory
and starting FF. What caused it to work was
overlooking/eliminating the old environment variable
setup constructed to make the earlier version of
TorButton operate correctly.

So these lines no longer apply,

export TOR_CONTROL_PORT="9151"
export TOR_CONTROL_PASSWD="guaranteed_to_fail"

presumably because some aspect of the major
revision is at odds with them.

Starting from KDE is not the issue.

comment:10 Changed 5 years ago by starlight

For some reason, even in the "green state", TorButton
does not appear to allow any cookies whatsoever.
So, for example, I can't establish a login session
for eBay.

I've grown frustrated with TorButton and have
come up with an approach that works and seems
safe enough:

1) disable TorButton and TorLauncher

2) configure history like this

set "use custome setting for history"
uncheck "always use private browsing mode"
check all four indented boxes
set "accept third party cookies to NEVER"
be certain the last "clear history when TBB closes" is set

So now if I exit FF and simultaneously tell the
relay to establish a "new identity", that would
seem to cover what TorButton does for the
less technical. The FF restart loop makes
exiting/restarting the browser no more painful
then what happens when TorButton "new identity'
is invoked.

Am I missing anything?

comment:11 Changed 5 years ago by mcs

Resolution: worksforme
Status: newclosed

I am glad you were able to get past the problem where Torbutton thinks tor is down. I have closed this bug.

However, by disabling Torbutton you are missing out on some protection that is only supplied by that add-on. Search for Torbutton in this document to learn more:

What you are missing may not be extremely critical, but it would be better if you could leave Torbutton enabled.

Please open a new ticket about the cookie problem when you have a chance.

comment:12 Changed 5 years ago by starlight

Tried turning TorButton, but not TorLauncher back on.

Now it's working. Seems that somewhere along
the way one of the updates forced the History
setting to "Never Remember", which implies
"Always use private browsing mode" and suppresses
setting of any cookies. I always copy 'prefs.js'
and 'places.sqlite' from one version install to
the next, though otherwise start with a fresh tree.

Probably that's a bug since many users
would not necessarily realize what had
happened. I didn't.

Note: See TracTickets for help on using tickets.