Re: [tor-relays] Handshake flood now on NTor

2014-09-08 Thread Tor Stuff
I have a related question. I have recently built my first Tor relay (ORPort
443, DirPort 80, NOT Exit) with both the bandwidth and burst limits set to
100KB/s.

It has been running for less than 3 days. During that time I have been
monitoring it with 'arm' and on GLOBE and notice a number of things that I
cannot reconcile:

1. The 'arm' download total ALWAYS exceeds the upload total. As a
percentage of the upload total the difference is 5%-6%. There are NO
unsuccessful handskakes recorded.

2. The bandwidth graph provided by 'arm' is headed: Bandwidth (limit: 800
Kb/s, burst 800 Kb/s, measured: 152.0 b/s):. It is the measured: 152.0
b/s that has me scratching my head! What does that value represent? Note
that 'arm' tells me that average bandwidth usage (up and down) is well over
10 Kb/s with instantaneous usage of more than 50 Kb/s at times.

3. Possibly related to 2) above, I ALWAYS seem to have more inbound
connections than outbound connections.

BUT in contradiction to the above, GLOBE says that for the 3-day period
monitored, written bytes (bandwidth?) is 1.84 bB/s while read bytes is
1.62 kB/s. That is, upload bandwidth is greater than download bandwidth.
That seems to me more reasonable than what 'arm' is saying as my relay is
willing to upload directory info.

Q

On Mon, Sep 8, 2014 at 6:58 AM, Joel Cretan jcre...@gmail.com wrote:

 I observed something similar today. It was basically as you described for
 the previous cases you observed, where there was a storm of about 10 times
 more TAP handshakes than usual. My middle relay is pretty small, limited to
 1.1Mbit/s, and until this point it wasn't even saturating that. Then this
 storm came in and saturated it for less than half a day, and then it
 stopped. My consensus weight went up during this time, so there is a higher
 level of residual traffic now than before it started, but the extreme event
 seems to done. It's strange to me that during the storm, the downstream
 traffic was much greater than the upstream. Any idea what could have been
 going on during that time? Why would my relay be receiving a bunch of data
 that it didn't pass on? The discrepancy seems to be too high for it to
 downloading directory information.

 The fingerprint is 7552CA84FB125059DC2959A6BE01A6A8107B3523 and here are
 the log entries from before, during and after:

 Sep 06 13:40:04.000 [notice] Heartbeat: Tor's uptime is 11 days 18:00
 hours, with 34 circuits open. I've sent 3.52 GB and received 3.52 GB.
 Sep 06 13:40:04.000 [notice] Average packaged cell fullness: 96.735%
 Sep 06 13:40:04.000 [notice] TLS write overhead: 6%
 Sep 06 13:40:04.000 [notice] Circuit handshake stats since last time:
 1948/1949 TAP, 645/645 NTor.

 Sep 06 19:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 0:00
 hours, with 878 circuits open. I've sent 3.64 GB and received 3.65 GB.
 Sep 06 19:40:04.000 [notice] Average packaged cell fullness: 95.657%
 Sep 06 19:40:04.000 [notice] TLS write overhead: 7%
 Sep 06 19:40:04.000 [notice] Circuit handshake stats since last time:
 16759/16957 TAP, 540/540 NTor.

 Sep 07 00:12:04.000 [notice] New control connection opened.
 Sep 07 00:25:03.000 [notice] New control connection opened.
 Sep 07 00:31:42.000 [notice] New control connection opened.
 Sep 07 01:14:06.000 [notice] New control connection opened.
 Sep 07 01:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00
 hours, with 161 circuits open. I've sent 4.03 GB and received 4.51 GB.
 Sep 07 01:40:04.000 [notice] Average packaged cell fullness: 93.753%
 Sep 07 01:40:04.000 [notice] TLS write overhead: 7%
 Sep 07 01:40:04.000 [notice] Circuit handshake stats since last time:
 36498/611731 TAP, 832/867 NTor.

 Sep 07 07:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 12:00
 hours, with 24 circuits open. I've sent 4.44 GB and received 6.22 GB.
 Sep 07 07:40:04.000 [notice] Average packaged cell fullness: 93.604%
 Sep 07 07:40:04.000 [notice] TLS write overhead: 8%
 Sep 07 07:40:04.000 [notice] Circuit handshake stats since last time:
 27191/1548070 TAP, 1261/1353 NTor.

 Sep 07 13:34:25.000 [notice] New control connection opened.
 Sep 07 13:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 18:00
 hours, with 19 circuits open. I've sent 4.61 GB and received 6.38 GB.
 Sep 07 13:40:04.000 [notice] Average packaged cell fullness: 93.745%
 Sep 07 13:40:04.000 [notice] TLS write overhead: 8%
 Sep 07 13:40:04.000 [notice] Circuit handshake stats since last time:
 1803/1803 TAP, 385/385 NTor.




 On Tue, Sep 2, 2014 at 11:28 AM, Jobiwan Kenobi helpme.jobi...@gmail.com
 wrote:

 Hi,

 For about 15 hours straight, my relay was being hammered by
 connections/handshakes.

 I see lots of these:

 Sep 02 01:03:02.000 [warn] Your computer is too slow to handle this many
 circuit creation requests! Please consider using the MaxAdvertisedBandwidth
 config option or choosing a more restricted exit policy. [70638 similar
 message(s) suppressed in last 60 seconds]

 Numbers vary between 3 and 

[tor-relays] Fwd: Handshake flood now on NTor

2014-09-08 Thread Tor Stuff
A correction to my posting below. With reference to what GLOBE says about
my relay, I meant to say mean written bytes (mean bandwidth?) is 1.84
kB/s while mean read bytes is 1.62 kB/s.

Q
-- Forwarded message --
From: Tor Stuff tor.geheimschrei...@gmail.com
Date: Mon, Sep 8, 2014 at 1:48 PM
Subject: Re: [tor-relays] Handshake flood now on NTor
To: tor-relays@lists.torproject.org


I have a related question. I have recently built my first Tor relay (ORPort
443, DirPort 80, NOT Exit) with both the bandwidth and burst limits set to
100KB/s.

It has been running for less than 3 days. During that time I have been
monitoring it with 'arm' and on GLOBE and notice a number of things that I
cannot reconcile:

1. The 'arm' download total ALWAYS exceeds the upload total. As a
percentage of the upload total the difference is 5%-6%. There are NO
unsuccessful handskakes recorded.

2. The bandwidth graph provided by 'arm' is headed: Bandwidth (limit: 800
Kb/s, burst 800 Kb/s, measured: 152.0 b/s):. It is the measured: 152.0
b/s that has me scratching my head! What does that value represent? Note
that 'arm' tells me that average bandwidth usage (up and down) is well over
10 Kb/s with instantaneous usage of more than 50 Kb/s at times.

3. Possibly related to 2) above, I ALWAYS seem to have more inbound
connections than outbound connections.

BUT in contradiction to the above, GLOBE says that for the 3-day period
monitored, written bytes (bandwidth?) is 1.84 bB/s while read bytes is
1.62 kB/s. That is, upload bandwidth is greater than download bandwidth.
That seems to me more reasonable than what 'arm' is saying as my relay is
willing to upload directory info.

Q

On Mon, Sep 8, 2014 at 6:58 AM, Joel Cretan jcre...@gmail.com wrote:

 I observed something similar today. It was basically as you described for
 the previous cases you observed, where there was a storm of about 10 times
 more TAP handshakes than usual. My middle relay is pretty small, limited to
 1.1Mbit/s, and until this point it wasn't even saturating that. Then this
 storm came in and saturated it for less than half a day, and then it
 stopped. My consensus weight went up during this time, so there is a higher
 level of residual traffic now than before it started, but the extreme event
 seems to done. It's strange to me that during the storm, the downstream
 traffic was much greater than the upstream. Any idea what could have been
 going on during that time? Why would my relay be receiving a bunch of data
 that it didn't pass on? The discrepancy seems to be too high for it to
 downloading directory information.

 The fingerprint is 7552CA84FB125059DC2959A6BE01A6A8107B3523 and here are
 the log entries from before, during and after:

 Sep 06 13:40:04.000 [notice] Heartbeat: Tor's uptime is 11 days 18:00
 hours, with 34 circuits open. I've sent 3.52 GB and received 3.52 GB.
 Sep 06 13:40:04.000 [notice] Average packaged cell fullness: 96.735%
 Sep 06 13:40:04.000 [notice] TLS write overhead: 6%
 Sep 06 13:40:04.000 [notice] Circuit handshake stats since last time:
 1948/1949 TAP, 645/645 NTor.

 Sep 06 19:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 0:00
 hours, with 878 circuits open. I've sent 3.64 GB and received 3.65 GB.
 Sep 06 19:40:04.000 [notice] Average packaged cell fullness: 95.657%
 Sep 06 19:40:04.000 [notice] TLS write overhead: 7%
 Sep 06 19:40:04.000 [notice] Circuit handshake stats since last time:
 16759/16957 TAP, 540/540 NTor.

 Sep 07 00:12:04.000 [notice] New control connection opened.
 Sep 07 00:25:03.000 [notice] New control connection opened.
 Sep 07 00:31:42.000 [notice] New control connection opened.
 Sep 07 01:14:06.000 [notice] New control connection opened.
 Sep 07 01:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00
 hours, with 161 circuits open. I've sent 4.03 GB and received 4.51 GB.
 Sep 07 01:40:04.000 [notice] Average packaged cell fullness: 93.753%
 Sep 07 01:40:04.000 [notice] TLS write overhead: 7%
 Sep 07 01:40:04.000 [notice] Circuit handshake stats since last time:
 36498/611731 TAP, 832/867 NTor.

 Sep 07 07:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 12:00
 hours, with 24 circuits open. I've sent 4.44 GB and received 6.22 GB.
 Sep 07 07:40:04.000 [notice] Average packaged cell fullness: 93.604%
 Sep 07 07:40:04.000 [notice] TLS write overhead: 8%
 Sep 07 07:40:04.000 [notice] Circuit handshake stats since last time:
 27191/1548070 TAP, 1261/1353 NTor.

 Sep 07 13:34:25.000 [notice] New control connection opened.
 Sep 07 13:40:04.000 [notice] Heartbeat: Tor's uptime is 12 days 18:00
 hours, with 19 circuits open. I've sent 4.61 GB and received 6.38 GB.
 Sep 07 13:40:04.000 [notice] Average packaged cell fullness: 93.745%
 Sep 07 13:40:04.000 [notice] TLS write overhead: 8%
 Sep 07 13:40:04.000 [notice] Circuit handshake stats since last time:
 1803/1803 TAP, 385/385 NTor.




 On Tue, Sep 2, 2014 at 11:28 AM, Jobiwan Kenobi helpme.jobi...@gmail.com
 wrote:

 Hi,

 For about 

[tor-relays] TTTT

2014-09-08 Thread Sebastian Urbach

Dear list members,

Just a quick update regarding :

Currently we are working on a technical paper based on the so far collected 
data. ETA is roughly 4 weeks from now on. The paper is going to hit this 
list asap.


--
Mit freundlichen Grüssen / Sincerely yours

Sebastian Urbach

--
Those who would give up essential Liberty,
to purchase a little temporary Safety,
deserve neither Liberty nor Safety.
--
Benjamin Franklin (1706 - 1790),  Inventor,
journalist, printer, diplomat and statesman


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


[tor-relays] enable-ec_nistp_64_gcc_128

2014-09-08 Thread Harold Naparst
If you want a version of openssl compiled with the
enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux,
you can grab it from my overlay:

layman -f
layman -a hnaparst
emerge openssl

The new flag nist is turned on by default.  I have 1.0.1i and 1.0.2_beta2
in the overlay.

Hope it helps.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] enable-ec_nistp_64_gcc_128

2014-09-08 Thread Jeremy Olexa
Thanks for your contribution, can you also add some note to the
underlying bug report https://bugs.gentoo.org/469976 so others may see
it easier?
-Jeremy

On Mon, Sep 8, 2014 at 2:52 PM, Harold Naparst har...@alum.mit.edu wrote:
 If you want a version of openssl compiled with the
 enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux,
 you can grab it from my overlay:

 layman -f
 layman -a hnaparst
 emerge openssl

 The new flag nist is turned on by default.  I have 1.0.1i and 1.0.2_beta2
 in the overlay.

 Hope it helps.


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

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