(Note: I tried the version of Tor in testing first.)

Here is the config line from my torrc:

ClientTransportPlugin obfs3 exec /usr/bin/obfsproxy --log-min-severity info --log-file /tmp/obfsproxy.log managed

And here is what I get in /var/log/tor/log on every restart:

"The communication stream of managed proxy '/usr/bin/obfsproxy' is 'closed'. Most probably the managed proxy
stopped running. <etc....>"

Then I added the logging bits in the ClientTransportPlugin line above. But, no /tmp/obfsproxy.log
file is created. However, if I run

	/usr/bin/obfsproxy --log-min-severity info --log-file /tmp/obfsproxy.log managed

straight from the command line, a /tmp/obfsproxy.log is created.
Perhaps there is an issue with the Debian environment?

Hi clayton,

clayton wrote (29 Dec 2014 10:23:43 GMT) :

Do you have AppArmor enabled?

Cheers!

Nope, not a trace of it.

I can't reproduce it.  Does that still happen on your system?  What does
an strace -f report?  What is your complete and uncensored
configuration?  What else is weird on your system?

Cheers,

On Fri, 20 Feb 2015 12:02:14 +0100 Peter Palfrader <weasel@debian.org> wrote:

As luck would have it, I just got a newer laptop and did a clean Jessie
install. My configuration works perfectly on the newly installed
machine.

On the old machine where things are not working, I updated everything.
Both machines are running an almost identical testing/Jessie setup
with a smattering of unstable packages, enforced in large part by
Puppet. I try to deviate from 'testing' as little as possible,
generally speaking.

I then purged both tor and obfsproxy, and re-installed. Still not
working.

My torrc (enforced by Puppet on both machines!) is very simple:

	ClientTransportPlugin obfs3 exec /usr/bin/obfsproxy
	--log-min-severity info --log-file /tmp/obfsproxy.log managed

	UseBridges 1

	Bridge obfs3 <IP>:<port> <key>
	Bridge obfs3 <IP>:<port> <key>
	Bridge obfs3 <IP>:<port> <key>

I can share the bridge details privately with you if it would be
helpful, but I re-iterate: this works on one of my machines.

The difference between the two machines is the broken one's install is
older, with the obvious consequences. I have at least one more machine
I am going to try this on, another day.

And now the final kick in the pants ;-) :

	strace -o /tmp/tor-strace.log -f /usr/bin/tor
	--defaults-torrc /usr/share/tor/tor-service-defaults-torrc

actually works! I get to "Bootstrapped 100%: Done" in the Tor log. But
if I then kill the strace'd process and go back and start Tor with
systemd, it fails again. I iterated a couple times, and it is
repeatable.

Perhaps an issue with systemd? Or a race condition (this is a slightly
older/slower machine, Thinkpad x201i)?

	apt-get purge install sysvinit-core

and then reboot with sysvinit resulted in no gain. Tor still cannot
start obfsproxy, same symptoms. I am inclined to no longer suspect
systemd.

Clayton

Do you have a /usr/sbin/aa-status?  If yes, and you run it, what's its
exit status?

On Wed, 25 Feb 2015 09:37:27 +0100 Peter Palfrader <weasel@debian.org> wrote:

Nope, /usr/sbin/aa-status does not exist. And no apparmor installed
anywhere. I have another machine that is even a bit older and slower, I
will try on that tomorrow if I get a chance.

Clayton

As promised, I just installed this configuration on another older
machine, a Thinkpad x60s which is even older than the x201i that is
failing. Also with an older install than the t410 where it is working.
The x60s is also not working, same symptoms.

So to summarize, we have working:

	t410: fastest, with a newly installed OS

We have NOT working:

	x201i, x60s: both with older installs, both slower machines

Everything up-to-date with the latest testing/Jessie, and a few
unstable packages.

Clayton