[tor-relays] Upgrade your relay to 0.2.4.17-rc?
Hi folks, I just released 0.2.4.17-rc. Hopefully there will be debs of it soon. It comes with a new feature: - Relays now process the new NTor circuit-level handshake requests with higher priority than the old TAP circuit-level handshake requests. We still process some TAP requests to not totally starve 0.2.3 clients when NTor becomes popular. A new consensus parameter NumNTorsPerTAP lets us tune the balance later if we need to. Implements ticket 9574. So the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing. Please consider upgrading. If you do, though, please also keep an eye on it -- it's possible we introduced some new bugs and the network will start dissolving once more relays move to the new version. In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. Aren't distributed systems fun, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On Thu, Sep 05, 2013 at 06:54:57AM -0400, Roger Dingledine wrote: In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On 09/05/2013 03:20 PM, Roger Dingledine wrote: On Thu, Sep 05, 2013 at 06:54:57AM -0400, Roger Dingledine wrote: In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays I updated one of our nodes to the newest version. Has this patch the nice side-effect of a better multicore handling? It's amazing that my 8 cores are now finally used. Greetings -- Sam Grüneisen - President of FVDE Frënn vun der Ënn is an NPO fighting for human rights with the help of technology. www.enn.lu ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On Thu, Sep 5, 2013 at 7:12 PM, Lunar lu...@torproject.org wrote: For those in a hurry, automatically built packages are available by adding the following in your sources.list: I see the following messages, which I was not seeing earlier. It eventually completes bootstrapping, 100%: Sep 05 22:04:03.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. Sep 05 22:04:06.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (DONE; DONE; count 10; recommendation warn ) Sep 05 22:04:06.000 [warn] 10 connections have failed: Sep 05 22:04:06.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object) Sep 05 22:04:06.000 [warn] 3 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE Sep 05 22:04:06.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection refused; CONNECTREFUSED; count 11; recommendation warn) Sep 05 22:04:06.000 [warn] 10 connections have failed: Sep 05 22:04:06.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object) Sep 05 22:04:06.000 [warn] 3 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE Sep 05 22:04:07.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection refused; CONNECTREFUSED; count 12; recommendation warn) Sep 05 22:04:07.000 [warn] 11 connections have failed: Sep 05 22:04:07.000 [warn] 8 connections died in state connect()ing with SSL state (No SSL object) Sep 05 22:04:07.000 [warn] 3 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] A bit more evidence on circuit creation storms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Just to add my experiences to the mix: I started running a RPi relay back in January. It ran fine for several months, until I started to get these circuit creation storms periodically. It would come at random times, maybe once a week, and would sometimes last for enough hours that it would knock down the Pi and I'd have to reboot it. While it was clearly CPU bound during the storms (90%+ shown by top), my bandwidth was also completely saturated. I was seeing 3 Mb/s traffic, as shown by ntop (great for monitoring bandwidth over time). Shutting down Tor during the storms would reduce the traffic to 100kb/s...so clearly the circuit storms eat bandwidth too. Gordon, perhaps you had an upstream router that was preventing the traffic flood during the circuit storms? I asked Roger Dingledine about it at PETS a couple months ago, and he suggested it might be a case where there is a nearby popular hidden service that picked my relay as a guard node, and all of a sudden I get flooded by requests for the hidden service. No idea how to test the accuracy of this hypothesis. Finally, I noticed that bandwidth-related config options had no effect on the 3 Mb/s traffic flood during the circuit creation storms. I had: RelayBandwidthRate 200 KB RelayBandwidthBurst 200 KB MaxAdvertisedBandwidth 200KB ...yet, still 3 Mb/s traffic floods. Even MaxOnionsPending 250, NumCPU 1, and AvoidDiskWrites 1 made no difference in my RPi's ability to weather the storms. I eventually had to use QoS on my DD-WRT router to set limits on the traffic it would pass to the Pi. I will try your builds of 0.2.4 to see if that makes a difference. cheers, Dan Since I originally started keeping an eye on these on my Raspberry Pi relay (read: slow, resource-limited), I've got to wonder if the circuit creation storms I was seeing months ago weren't normal network phenomena but some kind of test run. We are talking going from 50-250 circuits to thousands of requests per *second* out of nowhere, and then if the machine survived it, the storm disappearing as suddenly as it came. This was happening months ago, but less frequently and only on lower-end hardware. Now it's happening everywhere. Even if the previous case *were* normal Tor network operation, I'd say it's a bug, but I'm suspicious that it was whatever is going on now in its test phase. tor at t-3.net: Also see a repeat of the odd log message with the 154.x net address someone else described with the huge hexidecimal string (40 hex chars, + sign, 40 more, on and on). Here as well. I believe this is the sign of an overloaded Tor directory server. Over roughly the same time frame I received an incredibly high number of spam e-mails in one e-mail account that normally gets 20 or so a day on quiet days. Perhaps this is another example of mal-ware in action. Funny, one of the dropped connections during my storm last night was to port 993... :P Best, - -Gordon M. - -- http://disman.tl OpenPGP key: http://disman.tl/pgp.asc Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKInBAAoJEPZwdO29hkOpDZ4QAIjZqi9kXrcubZUg6v0nH6mP V9LT4j2Md0MqE74JcyEIgIBYKMWbun+n417LMMkb9uLu2mld6Lf/YIU9iO57JqQJ 8dM1uX0LJb51MbOj6ZTZEwMgHI8pX/ZeLj4zQscAz2C2oBwapnOpxqKTbg76CM1G DrP39iai9TpN+YfUY0FkxwdYTM46ADUvk/hbu/34CLXklOvrqWkK/Ta/nZ9zTebt HkB/KJn1P0I5L87x2VmIhIH5JKK6lszDlZg+k96PRC8oK9a1icECCGsnFJpqwVrv UyIsutezQHjT7HT4zJCNBxacHuK8VKbwayX6P/MSPpAGaobqEzSvWJmHdYRrIv2h glM5qIIzB3RmJxvHW8hCF47T8n9B6fo+J5PZly3xtwLGzCATjehnnhGTzigIw8ro WkQwMQr/3F5yQ0YS2YKh+KsQDhe2d1fYbrGtSPAG/z1RMuk2i5tmgyhAFJ8HvIfw GozzAaxcy1dCdEvQIyv/j1LCtUUpCrPVGd51grDI+GB9b5HuIEsPoQCvisshVEpu 1vLKyP7VLv+fOnvVb7MCwiWnU1Q5uw3yC3kdig9tTuAWGiMgbGoWpkGiy5MNVVQA Z2Q7uLnd7j6scTbpWgaa0Fx0HQ2euAXMwC+zS8g0PQXOEslGnnPs2Kqz5YTimtuh LWLcZ3WMZvlShurfNLse =mqNB -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
Don't know if this is update specific or just because of the new users in the network: 17:00:25 [WARN] Your Guard curiosity3 ($07AE80AA2F475282E3C08F589826C8FB19E8086B) is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Success counts are 93/248. Use counts are 91/91. 95 circuits completed, 0 were unusable, 2 collapsed, and 46 timed out. For reference, your timeout cutoff is 60 seconds. On 09/05/2013 04:14 PM, Sanjeev Gupta wrote: On Thu, Sep 5, 2013 at 7:12 PM, Lunar lu...@torproject.org mailto:lu...@torproject.org wrote: For those in a hurry, automatically built packages are available by adding the following in your sources.list: I see the following messages, which I was not seeing earlier. It eventually completes bootstrapping, 100%: Sep 05 22:04:03.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. Sep 05 22:04:06.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (DONE; DONE; count 10; recommendation warn ) Sep 05 22:04:06.000 [warn] 10 connections have failed: Sep 05 22:04:06.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object) Sep 05 22:04:06.000 [warn] 3 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE Sep 05 22:04:06.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection refused; CONNECTREFUSED; count 11; recommendation warn) Sep 05 22:04:06.000 [warn] 10 connections have failed: Sep 05 22:04:06.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object) Sep 05 22:04:06.000 [warn] 3 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE Sep 05 22:04:07.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection refused; CONNECTREFUSED; count 12; recommendation warn) Sep 05 22:04:07.000 [warn] 11 connections have failed: Sep 05 22:04:07.000 [warn] 8 connections died in state connect()ing with SSL state (No SSL object) Sep 05 22:04:07.000 [warn] 3 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sam Grüneisen - President of FVDE Frënn vun der Ënn is an NPO fighting for human rights with the help of technology. www.enn.lu ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Appropriate bandwidth limits for my home relay
Hi all, After running my relay for a bit on my home connection I found that Tor would happily consume all the bandwidth available, which (coupled with the number of connections overwhelming my home router, I suspect) caused my internet connection to be unusable for other things. So I set the RelayBandwidthRate and RelayBandwidthBurst values to 20 KBytes, as 20KBytes/s is a reasonable amount of bandwidth I can spare (total upload bandwidth on the connection is around 50KBytes/s). However now atlas.torproject.org shows an average of only around 0.5 - 1.5 Kbytes/s usage, and says the advertised bandwidth is 10 Kbytes/s. Should I increase the RelayBandwidthRate value to more than I can comfortably provide, on the basis that it isn't likely to all be used? Or should I just relax and let the network use my relay as little as it likes? Sometime quite soon my home internet connection will get much faster; I'm aware the relay is of questionable value at present bandwidth levels, but they should increase in not too long. Thanks, Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On Thu, 05 Sep 2013 17:04:15 +0200 virii vi...@enn.lu wrote: Don't know if this is update specific or just because of the new users in the network: I had this on 0.2.4.16, so not update-specific. -- With respect, Roman signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Upgraded to 0.2.4.17-rc and almost immediately got the following in my syslog: debian kernel: [5000394.949751] TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters. No idea what it means. 443 is my or port. Tor is running fine and bandwidth usage is growing. 50mbit/s atm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (MingW32) iQEcBAEBAgAGBQJSKJ5vAAoJEJ4b+e/7JJoUgnkIAJryAwVtekZMvwtFdfOTzO9c sKE1gxcvxdWJxD44UGUrIv88s5G9ROwU0e37LCW+L5YNWCCA/k0KS4ueZh8CFVXL DBK8b8XD5IXwSa5o2tex9P0BADj+pTl4ShqfIS/diOJukWEDfICgKh/Xa86GaDvo dbvEtKd6WqT8HbiP7TtlkJonAYDgOIb6mNre7a1W7sNAmwb2GLDZFX2BoAM+0rQK Sdb+oOtylO/12z0GK/YYVNvmxgJXf+GrGB24axCTZEwYAXPga3MAJkr0M3RcMNKx 27ViTkwQZxafjVR2+JXBWb8Bn7RnxO40GMI9ZE8F+Pa2jR2cVrUcEv84+aCDjgk= =W3uU -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Roger Dingledine: Hi folks, I just released 0.2.4.17-rc. Hopefully there will be debs of it soon. I will get binary debs for Raspbian completed this evening, and this time sign them with my public key[1] for anyone who chooses to trust me. It's quite easy, so I'll post a README about building from deb-src for those who don't wish to trust my binaries. The instructions are already on the Tor Project web site though. Thanks * 100 for your work on this. [1] 1EEFFBA3 - also attached below for your convenience. Best, - -Gordon M. - -BEGIN PGP PUBLIC KEY BLOCK- mQENBFIIHWwBCADSkqB1JQtrMnHAigieI4uhOFE4klu6OSr1pMVkYdI5LMkTc9kG dG/MnFrixOCR3X8tD4cFkPKPT1coxRNzHjcazhpz+ztnUXVEMt1LARVreh+Msl02 b6VaONIjJT8aJFf+9ysS1Y/esP5dwrOW9NdPD8TwE7Po17ZrEiJQ8Sb2hNOAvnLe AuG3h9A7BCe3//RRqBUv7Jc0VIjhnG0deh5e7IF+FY+1llamKZtsPRJMriGhGcmw f9vSmILVocpie41wAS60rHFeoI0zQJKjo+3SZovlJI/OW7CPrUDN3aJ+hXRVGYm6 HrTgdYKSb4obcQ1yiB+UZoP//U+tUVxPIQBHABEBAAG0REdvcmRvbiBNb3JlaG91 c2UgKGh0dHA6Ly9nb3Jkb24ubW9yZWhvdXNlLm1lLykgPGdvcmRvbkBtb3JlaG91 c2UubWU+iQE+BBMBAgAoBQJSCB1sAhsDBQkDwmcABgsJCAcDAgYVCAIJCgsEFgID AQIeAQIXgAAKCRA/46UaHu/7o5d0B/0RyKF4SCi4s6VOV6XTE4RjPUhJtka7YnOj bjcHEvS976/2oSbcemV8zxJUnLzO0TqgI8nCdddOGS+37sBt7+CXXis8XVneoSly 1r7Fx8vOPY/2dZjDb85uMLpUMBXWyHMLrG32yIud1UduC+r2MqelZq0loflTpk9d ghiYexmY5iMdEDfegAsOXPh7KzNHipeG5bjF0ohrWJUF7F3utdGBrTuitvuyO59q EDKBmfqPEonl7z+2HHPViWyaa0bw9q9Ee8Eb5CYjWLp/8KbKX6edKsIaVsuN0R+T h2J0cB3Hq/+Z61Q8DvqukRrpqyCkyz32Z39IF3kKeU/yni7fREhwuQENBFIIHWwB CADXMjO1xsvN30Dkt8qL7C7VYw8xOTgoT+tfIpjOI2daB16QGSxL3hvOj20ZbfRg 4J3m+VuxMz76/PhwhzaeRB3lmnzAXUGdFaTuUehWh+WclU9EXS2mR9zPbP2OJ4QL uCtCa0XkHHoL8NhVH/57mXnsW4vsN/DSjPTUvCwnsbHhmTIYw1zV8x+R7YUb/0mN rToHHqGREYK9THt1jby/LRVKEe0ARrKHeMyY3E5vzhRK+M6Nv2m6BYhtc1Y3kcLT iQ58K5d3feAy28QUM9CC713D7czKtz083Apst9lpBFMJQ/arhuOFzK4a2BugwFq7 ih31Af53VWPGMRYDVCraczklABEBAAGJASUEGAECAA8FAlIIHWwCGwwFCQPCZwAA CgkQP+OlGh7v+6ORCAf+Ka11bi/HCxc136cSHI9F5k0kfFZgZFUirfdB4MpTvxUb MQfkL/HJv5UQdG7qKmf4pLnvu7D/2aFmttlCgNxQf4f01fQXZ14rqw9xrXC6+bg6 mzGv+rZz+UTxTn/saIX+TtZ9GP+AXM+aDgOgk7kUCZcreGQMdzX/rkxj5fi+AsM5 mKDsq29VImL45xGAp+7W7JF9xDTAdEC68yX1YU1rwiSUCRpHn6KlfRKcAXYZAiaG KP7R0WLdrOIx3urheYNgkgiPOe6pKMwq25FAiWIa/BGZuJWhM2VoQbLaY+n4R0qe D+CF7JLDj3HHMwMUb+soYhT07Td7vRyXK2ka2Oi7vw== =xWdW - -END PGP PUBLIC KEY BLOCK- -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSKLczAAoJED/jpRoe7/uj1F8IAKmEKEszzhaPjuVefoGMvcUX Yq0VVIXXYfB2PrWtfgY2T0VPe5AaFN3VZNgtNLSJOjGzrx+nJg6Oq2uVd/rKu+ML RYq9kmH0WiE8b9cu/SPBAu/7BgKGWUGHH9tOGrQPI1ghdOgM1YpvKTObve3mdhzz KaMOLb0OTTBjyCfuBM+AoY/EwwO0TaeNiOqnCAxWgcAvHUhDxYmBQcjrBUGlqvhw eAuZ9dRa89U/xW3dsRJXncRY7LJ79k4NXwanz4hR90nrEfNEZHTbLk0paoDd8IDK blN5gSE2Oalj6hWz5VywwcmFTMeZD8sXDCrF6S/y/1RDOJqhb4JX1ICcNEp28LQ= =Mqt5 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nice, thank you :) Let's see, how Tor reacts on this :D Roger Dingledine a...@mit.edu schrieb: Hi folks, I just released 0.2.4.17-rc. Hopefully there will be debs of it soon. It comes with a new feature: - Relays now process the new NTor circuit-level handshake requests with higher priority than the old TAP circuit-level handshake requests. We still process some TAP requests to not totally starve 0.2.3 clients when NTor becomes popular. A new consensus parameter NumNTorsPerTAP lets us tune the balance later if we need to. Implements ticket 9574. So the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing. Please consider upgrading. If you do, though, please also keep an eye on it -- it's possible we introduced some new bugs and the network will start dissolving once more relays move to the new version. In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. Aren't distributed systems fun, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays - -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On Thu, Sep 05, 2013 at 06:54:57AM -0400, Roger Dingledine wrote: So the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing. Please consider upgrading. If you do, though, please also keep an eye on it -- it's possible we introduced some new bugs and the network will start dissolving once more relays move to the new version. I've upgraded noisetor to 17-rc. We were seeing memory consumption exceeding 2GB/daemon (leading to swap storms on our 4-daemon 8GB box), I'll keep an eye on it to see if we do better with 0.2.4. After 20 minutes of uptime with 17-rc I'm not seeing the CPU pegged like it was within minutes of restart with 0.2.3.25, even though we are pushing 220 Mbps already. According to perf top we're still spending a lot of time in circuit creation/teardown though: cycle% image symbol -- - -- 19.37% torcircuit_unlink_all_from_channel 11.56% libcrypto.so.1.0.0 bn_sqr4x_mont 5.74% torcircuit_get_by_rend_token_and_purpose.constprop.11 4.95% libcrypto.so.1.0.0 sha1_block_data_order_ssse3 3.56% libcrypto.so.1.0.0 bn_mul4x_mont_gather5 3.20% libcrypto.so.1.0.0 _vpaes_encrypt_core 2.03% libcrypto.so.1.0.0 _bsaes_encrypt8_bitslice 1.32% libssl.so.1.0.0ssl3_cbc_digest_record -andy ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
Updated torland family. Hope that the new version helps. One of the last messages before update to 0.2.4.17-rc: Sep 05 21:06:29.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. [434930 similar message(s) suppressed in last 60 seconds] Because of this the number of exit connections dropped significantly to 300-400. Before this DDOS the exit numbers were around 7000-1. Regards, Torland On Thursday 05 September 2013 06:54:57 Roger Dingledine wrote: Hi folks, I just released 0.2.4.17-rc. Hopefully there will be debs of it soon. It comes with a new feature: - Relays now process the new NTor circuit-level handshake requests with higher priority than the old TAP circuit-level handshake requests. We still process some TAP requests to not totally starve 0.2.3 clients when NTor becomes popular. A new consensus parameter NumNTorsPerTAP lets us tune the balance later if we need to. Implements ticket 9574. So the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing. Please consider upgrading. If you do, though, please also keep an eye on it -- it's possible we introduced some new bugs and the network will start dissolving once more relays move to the new version. In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. Aren't distributed systems fun, --Roger ___ 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
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On Sep 5, 2013, at 20:13 , Kevin C. Krinke wrote: Machine's performance and resource usage are all within allowed norms (in fact running better than the 2.3.x release). I concur with Kevin that this built is running smoothly: Sep 05 21:24:37.000 [notice] Circuit handshake stats since last time: 2138926/4064871 TAP, 22/22 NTor. Sep 05 22:24:37.000 [notice] Circuit handshake stats since last time: 1688832/2282251 TAP, 605/605 NTor. Cpu 16%, load 1.77, using 565 MB RAM. Average 5-6 MiB/s. // Yoriz On Sep 5, 2013, at 20:13 , Kevin C. Krinke wrote: Just a quick note on my exit node's stats: 17:46:33 [NOTICE] Circuit handshake stats since last time: 25849/25857 TAP, 117/117 NTor. 16:46:33 [NOTICE] Circuit handshake stats since last time: 7809/7810 TAP, 65/65 NTor. That's one heck of a climb on the TAP side. Machine's performance and resource usage are all within allowed norms (in fact running better than the 2.3.x release). Consistently running bandwidth in the 3-4 Mb/sec range both up and down. If anyone wants to externally monitor via whatever existing means; my node's ID is: OneTorST8 and fingerprint ID: EE9D7103D6013885BBF767D3B4F51CD0B9E59976 running version 2.4.17-rc-dev. -- Kevin C. Krinke ke...@krinke.ca 851662D2 - 5216953E0CBA1767D6064AB2DAC1902A http://kevin.c.krinke.ca/851662D2.asc ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?
On Thursday 05 September 2013 22:27:53 tor-admin wrote: Updated torland family. Hope that the new version helps. One of the last messages before update to 0.2.4.17-rc: Sep 05 21:06:29.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. [434930 similar message(s) suppressed in last 60 seconds] Because of this the number of exit connections dropped significantly to 300-400. Before this DDOS the exit numbers were around 7000-1. Just noticed that during bootstrap there are new warnings I never noticed before. Is this a known issue or should I file a ticket? Sep 05 21:56:12.000 [notice] Tor 0.2.4.17-rc (git-36eb3e0da4c3a821) opening log file. Sep 05 21:56:12.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Sep 05 21:56:12.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Sep 05 21:56:12.000 [notice] Configured to measure statistics. Look for the *- stats files that will first be written to the data directory in 24 hours from now. Sep 05 21:56:12.000 [notice] Your Tor server's identity key fingerprint is 'TorLand2 332895D092C2524A3CDE8F6E1498FFE665EBFC34' Sep 05 21:56:14.000 [notice] We now have enough directory information to build circuits. Sep 05 21:56:14.000 [notice] Bootstrapped 80%: Connecting to the Tor network. Sep 05 21:56:14.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Sep 05 21:56:14.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. Sep 05 21:56:15.000 [notice] Circuit handshake stats since last time: 599/782 TAP, 3/3 NTor. Sep 05 21:56:15.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (Connection refused; CONNECTREFUSED; count 10; recommendation warn) Sep 05 21:56:15.000 [warn] 9 connections have failed: Sep 05 21:56:15.000 [warn] 9 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (Connection refused; CONNECTREFUSED; count 11; recommendation warn) Sep 05 21:56:16.000 [warn] 10 connections have failed: Sep 05 21:56:16.000 [warn] 10 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (Connection refused; CONNECTREFUSED; count 12; recommendation warn) Sep 05 21:56:16.000 [warn] 11 connections have failed: Sep 05 21:56:16.000 [warn] 11 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 13; recommendation warn) Sep 05 21:56:16.000 [warn] 12 connections have failed: Sep 05 21:56:16.000 [warn] 12 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:16.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (Connection refused; CONNECTREFUSED; count 14; recommendation warn) Sep 05 21:56:16.000 [warn] 13 connections have failed: [..] Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 54; recommendation warn) Sep 05 21:56:21.000 [warn] 52 connections have failed: Sep 05 21:56:21.000 [warn] 51 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:21.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 55; recommendation warn) Sep 05 21:56:21.000 [warn] 53 connections have failed: Sep 05 21:56:21.000 [warn] 52 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:21.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 56; recommendation warn) Sep 05 21:56:21.000 [warn] 54 connections have failed: Sep 05 21:56:21.000 [warn] 53 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:21.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN Sep 05 21:56:21.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 57; recommendation warn) Sep 05 21:56:21.000 [warn] 55 connections have failed: Sep 05 21:56:21.000 [warn] 54 connections died in state connect()ing with SSL state (No SSL object) Sep 05 21:56:21.000 [warn] 1
[tor-relays] [ARM] Connecting to another host's control port with ARM: Connection refused.
Hello, Tor community. Quick, possibly noobish question. I'd like to use my desktop and connect ARM (running on the desktop) to the control port of a server running Tor on the same LAN, but it's refusing the connection. I'm running /sudo -u tor arm -i 10.0.0.3:9051/, and it outputs: robert@CPC-Arch:~$ sudo -u tor arm -i 10.0.0.3:9051 [sudo] password for robert: Connection refused. Is the ControlPort enabled? I can connect to the control port from the same host fine, but when I try to do it from another host it fails. There must be something I'm missing. Hope you guys can help me. Thanks. -Robert ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [ARM] Connecting to another host's control port with ARM: Connection refused.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06.09.2013 06:01, Robert Charlton wrote: Hello, Tor community. Quick, possibly noobish question. I'd like to use my desktop and connect ARM (running on the desktop) to the control port of a server running Tor on the same LAN, but it's refusing the connection. I'm running /sudo -u tor arm -i 10.0.0.3:9051/, and it outputs: robert@CPC-Arch:~$ sudo -u tor arm -i 10.0.0.3:9051 [sudo] password for robert: Connection refused. Is the ControlPort enabled? I can connect to the control port from the same host fine, but when I try to do it from another host it fails. There must be something I'm missing. Hope you guys can help me. Thanks. -Robert ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Well, 10.0.0.3 is a port on your LAN, while being on the same machine you may be able to connect to 127.0.0.1, which only refers to the local machine. Use netstat to find out, whether your control port is listening only on localhost or also on your LAN. You may then adapt the ControlPort option in your torrc to specify the interface you want it to listen on by specifing not only a port, but also an ip address, like ControlPort 10.0.0.3:9051 Note however, that this opens the ControlPort to all users on your network, so make sure your authentication is safe. Martin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKWE9AAoJEM1jnLOhksr36FUP/0UhfGu1vpf3AHpOCT9BA+ix 10sQisduMnSMbYXJammdtE3UGu9C4OOq0tTRMg34e+7I1esyarSvVnKF4Vd6+YtA BDRm38sMs+NFdLg2tEKJgsi8J3kp9GrFm3xee+MhhuBG0TZ+Yf2s6eal8XxtBy0m 5wSmZrR0jX9a8AdMkirIvP5+Y9IL+QAcmnV5esOTx6w6oaiDwZpm1p7sjEI9WCrM SSjSKXpM3CiDBfSnSVNbU1oQpzlVOubYOrG0leJEvTYftvRIvSTu0sDZSCkVViwn lZGdl48zF3/qQ01JEURXtCcVEOljOqptkVlESCb3DkxBZwe8iJK3uI2JDvkXtCxI QOmSaeCGLrDRUPA8XiZYC8WijFhUcy4RbQ/l0/4q0w1W7iyz6i9PQMeYT4S8IFbm 2MZaAnap6BWTlDoRtMYpm3n6SQnPUlBL6HtAvfgG4h0Kzj6A7xieRb7pQwodSETz TUA2jEUHEW2tFtu/3zQAiYA42cR6fKTh/YhIJNZulkbUbpqi9i2lVTm5jP8VMQrv 2vO920OYbLy1FsEL5AP/1kVLRYSoFOZtzilRvRFmusBsuOlEM4Gl1NUXuiWrz3GH 8UTFeVwRycA4nIX9/idRVIxkswapOk1V+M5wMemBZuedbWBqMfEm32H1FkS821A4 erbjHsg+yIPh0pmqhrpD =I1mE -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
