Re: [tor-dev] Pluggable transport weekly meeting

[Ximin Luo]

I assume people will be interested in creating Debian packages for these too. I 
am wondering if we should adopt a naming convention like tor-pt-sshproxy, 
tor-pt-flashproxy, tor-pt-obfsproxy etc - like how mozilla extensions are all 
called xul-ext-*. (We could even start a working group too.)

ATM this would involve renaming obfsproxy, but I am about to package 
flashproxy, and thinking about what to name the package.

X

On 06/09/13 13:44, Griffin Boyce wrote:
> That day and time work well for me -- thanks for setting this up! =)
> 
> ~Griffin
> 
> On 09/06/2013 04:58 AM, Vmon wrote:
>> I sent this email quite a while ago and I was surprised that nobody
>> was interested/replied. Today I found out that I had sent it to a
>> wrong address. But here we are, so I'm sending it again. So please
>> reply so we can kick this off soon.
>>
>> Thanks,
>> Vmon
>>
>> -- Forwarded message --
>> From: mailto:vmonmoonsh...@gmail.com>>
>> Date: Wed, Aug 21, 2013 at 6:46 AM
>> Subject: Pluggable transport weekly meeting
>> To: tor-dev-requ...@lists.torproject.org
>> 
>>
>>
>> Hello Tor devs,
>>
>> Following up on what we came up with in the dev summit
>> (https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMeeting/PluggableTransports1),
>> we are going to have weekly 30-minute IRC meeting focusing on pluggable
>> transports. The format (I think) will be scrum-esque that every
>> developer who is working on a pluggable transport will update everybody
>> else about the work they did/are doing on their transport during the
>> week and ask questions if they have any, for example if they got stuck
>> somewhere and they think somebody can help.
>>
>> Preliminary, we decided to have the meeting on Fridays, cause why not,
>> but if you have serious problem with Fridays then we might be able to
>> pick a better day.
>>
>> For the time of the meeting, considering the geographical positions
>> of the current transport developers, we'll probably end up having a CEST
>> evening and PST morning meeting. Having that in mind I suggest:
>>
>> CEST: 18:00
>> BST (Summer GMT): 17:00
>> EST: 12:00
>> MNT: 10:00
>> PST: 9:00
>>
>> So if this doesn't work for you, please reply to this email with your
>> alternative proposal.
>>
>> Thanks,
>> Vmon
>>
>>
>>
>> ___
>> tor-dev mailing list
>> tor-dev@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> 


-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Pluggable transport weekly meeting

[Lunar]

Ximin Luo:
> I assume people will be interested in creating Debian packages for
> these too. I am wondering if we should adopt a naming convention like
> tor-pt-sshproxy, tor-pt-flashproxy, tor-pt-obfsproxy etc - like how
> mozilla extensions are all called xul-ext-*. (We could even start a
> working group too.)
> 
> ATM this would involve renaming obfsproxy, but I am about to package
> flashproxy, and thinking about what to name the package.

I have heard people making the argument that obfsproxy, at least, was
not specific to Tor and could perfectly be used with plain SSH. The
prefix “tor-pt-” would not really be appropriate then.

-- 
Lunar 


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Quickly testing TOR using Chutney and Fluxcapacitor

[Marek Majkowski]

Tor ships with some testing facilities (tor/src/test/test), but they
are not comprehensive.  (I'm aware there's an ongoing effort on
improving these tests).

To test anything non trivial it is necessary to run a tor node as a
part of a tor network. There is another tool called chutney [1] that
can be used to set up a small testing Tor network: it generates plenty
of torrc configs and spawns a number of Tor servers locally.

This is very handy, but it can take a while before the network starts
working - the Auth servers need to establish the consensus and do all
the things I have no clue about.

Here's a simple shell script [2]:
 - It uses chutney to start a testing tor network.
 - It waits for it to work by trying to establish a connection to localhost:22.
 - Finally it tears down the network.

Normally it takes around 5 minutes for the network to converge:

$ time ./go.sh
real4m8.330s
user0m2.064s
sys 0m0.392s

Of course, you don't have to set a completely fresh Tor network for
every single test, but that's what I often do. I'd be eager to hear
how people are reusing chutney networks.

In past I wrote this thing called fluxcapacitor [3], it's a tool that
speeds up tests. After a few fixes I was able to run chutney on it:

$ time /tmp/fluxcapacitor/fluxcapacitor ./go.sh

real0m11.450s
user0m2.340s
sys 0m2.120s

Running stuff under fluxcapacitor is not deterministic, sometimes it
takes 8 seconds, sometimes 15 but it generally works and should go
pretty quick.

That's it. I thought someone may find it useful.

Cheers,
Marek


[1] https://gitweb.torproject.org/chutney.git
[2] https://github.com/majek/dump/blob/master/tor/go.sh
[3] https://github.com/majek/fluxcapacitor.git
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Testing flash proxy infrastructure

[David Fifield]

George asked me for tips on testing flash proxy infrastructure.

You will need to run a websocket-server
(https://gitweb.torproject.org/flashproxy.git/tree/HEAD:/websocket-transport)
in front of a relay:
ServerTransportPlugin websocket exec /usr/local/bin/websocket-server 
--port 9901
Or you can just use the public one at 173.255.221.44:9901. Let's
say the websocket-server is listening at 127.0.0.1:9901.

You follow these instructions to set up your own facilitator.
https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/facilitator-howto.txt
It's fairly involved, and at the end you have an Apache serving a CGI,
plus some local daemons. For your own local testing, you can use a
self-signed certificate or even plain HTTP, and you probably don't want
to do the email poller because that's a process on its own.

In /etc/init.d/facilitator, edit the RELAY variable to point to your
chosen websocket-server.

Say your facilitator CGI is running at https://facilitator:8000/. You
point flashproxy-client to the faciltiator using the -f option.
./flashproxy-client -f https://facilitator:8000/ --external 
--register-methods=http --unsafe-logging
To run flashproxy-client in managed mode from torrc, remove --external.

The two rendezvous methods that don't require setting up a lot of stuff
are http and url. You can add a client registration like so:
./flashproxy-reg-http -f https://facilitator:8000/ --unsafe-logging
./flashproxy-reg-url -f https://facilitator:8000/ 
--facilitator-pubkey=reg-daemon.pub 127.0.0.1:9000
With flashproxy-reg-url, you will have to paste the URL it prints out
into a browser. flashproxy-client will automatically pass the -f option
to its registration helpers.

To run a local flash proxy, open a non-Tor browser to embed.html and
give it the custom facilitator URL:

file:///home/user/flashproxy/proxy/embed.html?debug&facilitator=https://facilitator:8000/&initial_facilitator_poll_interval=0
To bypass the facilitator and connect directly to a client and relay, do
this:

file:///home/user/flashproxy/proxy/embed.html?debug&client=127.0.0.1:9000&relay=127.0.0.1:9901

David Fifield
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quickly testing TOR using Chutney and Fluxcapacitor

[Linus Nordberg]

Marek Majkowski  wrote
Sun, 8 Sep 2013 17:35:24 +0100:

| In past I wrote this thing called fluxcapacitor [3], it's a tool that
| speeds up tests. After a few fixes I was able to run chutney on it:
| 
| $ time /tmp/fluxcapacitor/fluxcapacitor ./go.sh
| 
| real0m11.450s
| user0m2.340s
| sys 0m2.120s
| 
| Running stuff under fluxcapacitor is not deterministic, sometimes it
| takes 8 seconds, sometimes 15 but it generally works and should go
| pretty quick.

Interesting approach, thanks for sharing.

Did you try running make test-network under fluxcapacitor?

It uses the bootstrap-network.sh in Chutney and should be able to
bootstrap a network in under 30s, without help.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quickly testing TOR using Chutney and Fluxcapacitor

[Nick Mathewson]

On Sun, Sep 8, 2013 at 12:35 PM, Marek Majkowski  wrote:
> Tor ships with some testing facilities (tor/src/test/test), but they
> are not comprehensive.  (I'm aware there's an ongoing effort on
> improving these tests).
>
> To test anything non trivial it is necessary to run a tor node as a
> part of a tor network. There is another tool called chutney [1] that
> can be used to set up a small testing Tor network: it generates plenty
> of torrc configs and spawns a number of Tor servers locally.
>
> This is very handy, but it can take a while before the network starts
> working - the Auth servers need to establish the consensus and do all
> the things I have no clue about.
>
> Here's a simple shell script [2]:
>  - It uses chutney to start a testing tor network.
>  - It waits for it to work by trying to establish a connection to 
> localhost:22.
>  - Finally it tears down the network.
>
> Normally it takes around 5 minutes for the network to converge:
>
> $ time ./go.sh
> real4m8.330s
> user0m2.064s
> sys 0m0.392s
>
> Of course, you don't have to set a completely fresh Tor network for
> every single test, but that's what I often do. I'd be eager to hear
> how people are reusing chutney networks.
>
> In past I wrote this thing called fluxcapacitor [3], it's a tool that
> speeds up tests. After a few fixes I was able to run chutney on it:
>
> $ time /tmp/fluxcapacitor/fluxcapacitor ./go.sh
>
> real0m11.450s
> user0m2.340s
> sys 0m2.120s
>
> Running stuff under fluxcapacitor is not deterministic, sometimes it
> takes 8 seconds, sometimes 15 but it generally works and should go
> pretty quick.
>
> That's it. I thought someone may find it useful.
>
> Cheers,
> Marek

Thanks, Marek!  This looks quite useful.  Can you talk a bit more
about under what circumstances (if any) the fluxcapacitor code there
might give incorrect results?

Also, I had thought the quick-and-dirty chutney test we shipped (via
./src/test/test-network.sh)  bootstrapped in faster than 5 minutes.
Am I wrong there? Does it use any tricks that might be helpful in
combination with fluxcapacitor?

best wishes,
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Quickly testing TOR using Chutney and Fluxcapacitor

[Marek Majkowski]

On Sun, Sep 8, 2013 at 10:12 PM, Nick Mathewson  wrote:
>> $ time /tmp/fluxcapacitor/fluxcapacitor ./go.sh
>>
>> real0m11.450s
>> user0m2.340s
>> sys 0m2.120s
>>
>> Running stuff under fluxcapacitor is not deterministic, sometimes it
>> takes 8 seconds, sometimes 15 but it generally works and should go
>> pretty quick.
>
> Thanks, Marek!  This looks quite useful.  Can you talk a bit more
> about under what circumstances (if any) the fluxcapacitor code there
> might give incorrect results?

Depends how you define "incorrect results". In a single-process
scenario fluxcapacitor, of course, will always work correctly and
predictably. When running in multi-process setup (as with Chutney) the
"results" are somewhat dependent on the kernel scheduling order.

In the worst case fluxcapacitor might "speed up" a wrong process and
cause a timeout to fire when it shouldn't. This is caused by kernel
giving CPU to FC rather than a child process that has more immediate
work to do. This is generally a hard problem on busy systems and I'm
still trying to find a right balance between FC speed and stability.
In normal circumstances this problem shouldn't show up, it occurs only
when the host is very busy and there is a heavy deficit of cpu power.

In theory the running time of a script under FC should be a constant -
it should be purely CPU bound. In reality it varies due to
indeterminism of kernel scheduling (and _plenty_ of context switches
and page misses).

Fortunately, as I have shown in the example, it's possible to run
exactly the same testing script with and without FC. If there is a
suspicion FC is malfunctioning, you can always run the tests without
it.

> Also, I had thought the quick-and-dirty chutney test we shipped (via
> ./src/test/test-network.sh)  bootstrapped in faster than 5 minutes.
> Am I wrong there? Does it use any tricks that might be helpful in
> combination with fluxcapacitor?

I was not aware of this script. I'll take a look.

Marek
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Pluggable transport weekly meeting

[Ximin Luo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/09/13 15:33, Lunar wrote:
> Ximin Luo:
>> I assume people will be interested in creating Debian packages for
>> these too. I am wondering if we should adopt a naming convention like
>> tor-pt-sshproxy, tor-pt-flashproxy, tor-pt-obfsproxy etc - like how
>> mozilla extensions are all called xul-ext-*. (We could even start a
>> working group too.)
>>
>> ATM this would involve renaming obfsproxy, but I am about to package
>> flashproxy, and thinking about what to name the package.
> 
> I have heard people making the argument that obfsproxy, at least, was
> not specific to Tor and could perfectly be used with plain SSH. The
> prefix ?tor-pt-? would not really be appropriate then.
> 

That is an argument that supports keeping the current name, but not directly a 
counter-argument against changing it.

I'd say that if a package advertises managed mode (using the Tor managed PT 
envvar/stdio protocol) as its primary usage, then it clearly thinks of itself 
primarily as a Tor PT, and so it's a good candidate for being named tor-pt-*. 
(obfsproxy does this.)

- -- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSLQVNAAoJEIYN7zuPZQt5EEoP/RzPPkMVjPvYfOb8CMF8UEa4
vWp1rrNc3w8nurH5/GWIcuxnIjm/9FzAxAI3tKGajX6RV9jvH364wNIgy4moXBLc
0070ItZB7UKHTLhGr7cbyPG11y1nyVpy4dw0fJFs6t9aYHWHBVbuWONDTbUm+T7D
xFyql3CimIA3TvF/hE0G2wNSdxm2DbNfy3vTp32jhPanYVTyaUcRxEwYBo9LMkvh
ShU4O0IsyRHSCIAKxNVxvLnwsJQS8ipTpHKTo+qfAUtRQTzl9hfzaP7/RjL6NNUN
LQLzU9vlOcyA2tCmZKbKzGrp1QzFksWRIz4UY+uqKxnJWLODO8FtEEwS/BMc6G3g
zcxRVsjqOxvdfy31MM/LCvm0wu2fWanovrkXTxOHCqsNl3io3w6pVpSTny4NvmKe
wm3AVf/mBIn/ZwYY7UiPpH+ClsgsT7Vu6gzYM+2Zct0gxd3+KL9GI5pVwt1AQ2QA
tAvclEQuRgu+tTHZgHCA1GVdQNhaOqjq3EI3BA1PYN1xS5ite2Hd6pI1lo8TFCIJ
xBcVn4hG9mVgSDaKndtxgNea3qLxFW9tTSfUMykVsHajuOlrM/7FsgvB4ljsmFYD
OaGnB8xp/0vBH0+mXcOlMan3FOfAW/TQRVreTT4goxpcCNpWLT5hU5AzQ8QkLQUx
ky2sGNRzSwuN6xzKk4/r
=A8e2
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor on the Beaglebone Black

[Joshua Datko]

I've been running a relay on a Beaglebone black for about two weeks
now and I'm wondering where to take this thing.  The Beaglebone black
is a 1GHz armhf System on a Chip, with 512 MB RAM.  At the moment,
it's a dedicated relay running Ubuntu (raring) but Debian is equally
as easy to setup.  I have a post with very basic installations:
http://datko.net/2013/08/24/beagleboneblacktor/

So, what next?  I looked at the torrouter project and I think I would
have to probably have to redo the roadmap to suit the Beaglebone.
Also, there is only one onboard NIC, so I'm not sure if that's a show
stopper.  I was going to do a fresh install of Debian, install Tor and
then build an image so that it could be booting (or flashed to the
eMMC) from a SD card, but wether that's better than installing tor
oneself, I don't know.

Anyway, just throwing an idea out there.  Thanks everybody for the
work on tor and I'm happy to be running a relay now.

Josh
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev