- tor-relays - lists.torproject.org

Average packaged cell fullness - decreasing recently
by Kees Goossens 22 Jan '15

22 Jan '15

Dear all, According to the log file of freshhumbug, the average packaged cell fullness always decreases after restarting my relay. This seems to have initiated mid/late October 2014,:-before then the packaged cell fullness was more or less constant. Whatever the measure exactly means, this doesn’t seem right. Hibernation has no impact, i.e. the fullness decreases from before to after hibernation. Could anyone comment on whether this is true but not to worry, or true and to worry, or not true (and not worry)? Graph enclosed (start=23 July 2014, end=today, running more or less all the time, apart from a little hibernation), showing the Nth ‘Averaged packaged cell fullness’ message in the logfile on the X axis and its value on the Y axis. (i.e. X axis does not exactly represent 6 hour intervals due to occasional hibernation.) The steep increases coincide with restarting the relay. Thanks. Kees

1 1

uptime and connections for my middle node relay
by Malte Ketelsen 20 Jan '15

20 Jan '15

Hi, I am running a relay about 5-6 weeks. I have read the 'lifecycle-of-a-new-relay' and I am not over the 86 days, but I still wonder me, at most, I have only inbound connections. Sometimes outbound too, but rarely. Can someone tell me why? And I have another question: Can someone tell me how many hours a day uptime is minimum requirement for a standard middle relay? I have reed many posts, but there are not a exactly answer. Sorry for my english ... greets Malte

2 2

MiB / metrics
by Sebastian Urbach 20 Jan '15

20 Jan '15

Hi, Karsten, thank you very much for your outstanding performance. I never expected that my wish/ticket would be implemented that fast ! -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

1 0

MiB/s / metrics
by Sebastian Urbach 20 Jan '15

20 Jan '15

Hi, I opened a ticket recently with the intention to use a more common unit than MiB/s for metrics. Karsten basically agrees but is waiting for more input. If someone is interested : https://trac.torproject.org/projects/tor/ticket/14257 -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

4 3

Mismatched fingerprints
by Patrick Scharmer 20 Jan '15

20 Jan '15

Hi, I’ve been running a bridge for over a year and noticed recently that the fingerprint shown in ARM (and that actually works when connecting to the bridge) differs from the fingerprint displayed for my bridge on both Atlas and Globe. Any thoughts on why this would happen and how to fix it? I’m assuming the fingerprint published on Atlas & Globe is the same fingerprint that will be distributed by bridges.torproject, is that correct? Apologies if this is a common question… I’ve only recently joined the mailing list and couldn’t find a way to search the archives other than browsing. Regards, -Pat

4 4

New Arris TG1672 Cable Modem, relay not reachable...help!
by Kurt Besig 19 Jan '15

19 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been running a middle relay for nine months with great success, however yesterday my ISP, TWC, upgraded my cable modem and everything went south. Then unfortunately there was a firmware upgrade for my Asus RT-N66U router. Perfect storm, now My relay is down, DirPort[80] and ORPort[443] unreachable. The new router admin interface looks like something written in Greek to me and although I've forwarded 443 and 80 there's still no joy. After almost a year of seamless connectivity I may have forgotten some important setup fact, but other than the modem and router firmware update my setup hasn't changed same computer, same Ubuntu LTS 14.04, same Tor 0.2.5.10... Anyone familiar with this Arris TG1672 modem, Assus' latest RT-N66U firmware 3.0.0.4.376.3754, or any general help would be most appreciated.. horizons3 My old IP:76.91.226.105 New IP:108.185.28.227 dhcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUvDFDAAoJEJQqkaGlFNDPIroH/1iXuYVs/aktiL8OhsCoKUbd uarWayXPQSh6DXT+OMFSpy/qkE1kQVP3dNqwuaP9GVwxrJ7Qqr6Suhrmlak7Npel 6BvgQGcTwhsGGtI+KiS4IyVAjjkPcltXOyHCgOELeE8tBjyWsaYuoRJkI48CnZM9 GE+dWy2MXribEZ75IpCl3/qmE1vqdSU4LONtqfMNZ+buFkCp5BhQ5QkiRH+qpOBG tbEuV2CK+2smlWOnK84v0bqfgcj08iWGOOSMu3+Cwc+8j2XI4fi2qMfsbfrq9Qqp spwOhlTtafxJvgf57ul5gY5Vdo9HH5OtZYBwd+SjVGOE0f4qNgXjqRxostKRSmE= =XGLP -----END PGP SIGNATURE----- --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

5 5

How to get NAMED Flag
by webmaster 18 Jan '15

18 Jan '15

Hello people out there, whats the actually procedure to get a NAMED Flag? -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+ zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0 lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5 EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk ZRMbezQ= =Med3 -----END PGP PUBLIC KEY BLOCK-----

2 1

weather torproject buggy?
by elrippo 17 Jan '15

17 Jan '15

Hy all, i wanted to list my relay on weather.torproject.org. When i submit, i get a 403FORBIDDEN [CSRF verification failed. Request aborted] What does that mean? Kind regards, elrippo -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo(a)elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 -----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 MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL -----END PGP PUBLIC KEY BLOCK-----

2 2

Linode, DigitalOcean
by Dave Warren 16 Jan '15

16 Jan '15

I've got a number of servers on Linode and DigitalOcean that could potentially be candidates for relays or bridges as they have a fair amount of otherwise unused resources. However, I wonder if there are enough people running non-exit nodes on these providers due to their large scale, such that more doesn't really help due to the lack of overall diversity of the network. Thoughts about whether running a few Tor relays in these environments is worthwhile? Neither is friendly enough to run exit nodes, at least as far as my purposes go. And to be clear, my goal is to utilize and share some otherwise unused resources, not to buy new servers to dedicate to Tor. While we're also debating sponsoring or operating exit nodes, they will be on dedicated servers in Tor friendly environments. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren

2 1

Re: [tor-relays] building Tor against LibreSSL 2.1.1 fails with "undefined reference to `EVP_aes_128_ctr'" error
by teor 15 Jan '15

15 Jan '15

> Date: Fri, 21 Nov 2014 07:22:10 -0800 > From: Seth <list(a)sysfu.com> > > I'm trying to build tor-0.2.5.10 from source against LibreSSL 2.1.1 on a > FreeBSD 9.3x jail system. > > It fails with this message > > ----------------------------------- > > CC src/tools/tor-gencert.o > CCLD src/tools/tor-gencert > src/common/libor-crypto.a(aes.o): In function `aes_new_cipher': > /usr/local/src/tor-0.2.5.10/src/common/aes.c:100: undefined reference to > `EVP_aes_128_ctr' > *** [src/tools/tor-gencert] Error code 1 > > Stop in /usr/local/src/tor-0.2.5.10. > *** [all] Error code 1 > > Stop in /usr/local/src/tor-0.2.5.10. > > -------------------------------------- > > Has anyone has any luck building Tor against LibreSSL? > Yes, on OS X, but it wasn't easy, and it didn't bootstrap for me due to SSL errors. Others have had more luck, but mostly on Linux AFAIK. Do you perhaps have a system-installed OpenSSL 0.9.* which is lacking EVP_aes_128_ctr? See https://trac.torproject.org/projects/tor/ticket/13817 for a similar failure, due to the following issues: configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR/bin/openssl" isn't in the path before all other openssl executables. configure --enable-static-openssl requires LDFLAGS="$OPENSSL_DIR/lib":$LDFLAGS to link properly, at least on OS X. If you do run into runtime SSL errors, see this bug: https://trac.torproject.org/projects/tor/ticket/13816 teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

4 11

new relay - large variation in consensus weight
by Abhiram Chintangal 14 Jan '15

14 Jan '15

Hello all, I am running a middle relay on a digital ocean [1] for roughly about a month now. While the process has been fairly straight forward, in the last few days I have noticed a large variation in the relays consensus weight. Right now it is close 1000 a few days before it was 300. Is this regular behaviour? Cheers! -- Abhiram Chintangal [1]: https://atlas.torproject.org/#details/3045303283D4EAF74C8FA053054C691BB451A…

1 0

You relay isn't getting indexed by Authorities?
by Dedalo 13 Jan '15

13 Jan '15

Some months ago I started running another tor relay (middle relay) and something happened, My relay wasn't getting indexed by any authority, neither wasn on atlas. A friend recommended me to make some tests, the problem was the ISP had blacklisted 6 Authorities, but to figure out this I had to make some tests... I made a very simple script which tests if your isp has blacklisted any authority or if you have a problem with your DNS... https://github.com/Dedal0/TorAuthoritiesScript Just run the script in the vps before you setup a relay to avoid indexing problems... The script makes a simple test but is efficient in most of authority cases. Regards, Dedalo -- twitter: @SeguridadBlanca Github: Dedal0 Blog: https://blog.dedalo.in

5 4

Extreme Overclocking / Relay Performance
by Thomas White 13 Jan '15

13 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Having discussed this with my partner earlier today, I am curious as to what knowledge the community might have on overclocking a CPU or using other speciality hardware to create an ultra fast Tor relay. I am aware of what IPredator have done but I feel confident better can be done. Has anyone looked into FPGA's at all or know what features, other than AES-NI enabled CPUs could bring big performance boosts? T - -- Activist, anarchist and a bit of a dreamer. Mirror & Keys: http://bbbbbb6qtmqg65g6.onion PGP Keys: key.thecthulhu.com Current Fingerprint: E771 BE69 4696 F742 DB94 AA8C 5C2A 8C5A 0CCA 4983 Key-ID: 0CCA4983 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Key-ID: EF1009F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 4321B19F A9A3462C FE64BAC7 294C8A7E A53CC966 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUspxJAAoJEFwqjFoMykmDAIEP/28IkrYhjvcnF2jPrt4AL7St 0uXbnTlWbe7KcbnDykXoKGoHwS5jYY7kK9wUo/wKxjxW8MjBlMQdbBiyrpGmc+CY Zk5LyfGkWpSG36KM1L4euK7DMOB5vucFwh4qdt4MEWcB5RZvO2BsuADiMqKQ+Ysz lcdnAmZuFlt+FxoS0O76FEpmahPoVKB5rC8i+pvRxRW14sliIJqVB3JKuE4SA66e 4bT+AGw6btddMO+uW6tDEJeib+fjkvcmCFKMcElr7YcUisJMQrxe8l/CxfrO2WvK nvlt0UMbg2WpPNVueW3uk//fKCZJJryOlo0fx3Mjg/DLAG6to9g0oBE1jQ740Qmz 0pzkxLodQ+FqnJONUgx+QY0spK4gUHXpBEv0lbKqzLSuhK47Nqd3KGd1eRPcpU// NM1tLXosYLHkaLnM98Cz6Bw1cxfMuO36KzLPXEuH2+6hhYTA4mABc4itAA6iRvw4 Ck8ohAlc6KYWqGL64nvOtIPUDYpQPkwLTClVf7PxJZP/CPaNTyI2fOuxM2ObW5Ca qGiCOPzvG1BtzP52IlGF3yfB9+711DvpgnUH4l/jS4KP4jsM2uFte/Z7DuRJXWi4 O0xfnZtqI4lWnNGV6RsbC8avJCrvou3XrWvMSzmU7AaEBQY0UoOK8eRXv/Em/Pv6 sQCc5pBSZgNQMTgunvxE =lX1H -----END PGP SIGNATURE-----

2 1

Re: [tor-relays] Reminder: don't run transparent proxies at exits
by teor 12 Jan '15

12 Jan '15

> Date: Mon, 12 Jan 2015 01:04:58 -0500 > From: grarpamp <grarpamp(a)gmail.com> > To: tor-relays(a)lists.torproject.org > >>> On Fri, Jan 9, 2015 at 10:26 PM, Drake Wilson <drake(a)dasyatidae.net> wrote: >>> eric gisse wrote: >>> Plus the logic starts to get warped when you wonder "So do you BadExit >>> every node that runs on an ISP that caches traffic?" >>> <snip> > > As far as http caching, it would be relatively fine IF the cache > truly did good practice, and IF the site truly did good design > for the cache to follow. However those two necessary truths > are often false, whether by AND or XOR context. So to be > true, a cache shouldn't be deployed, but in the interest of > bandwidth they are, more commonly at small end-tier user > access ISPs (including exits) for that purpose. > > I'd suggest best practice is for > - users to use https to bypass > - caches to insert their tagline in http headers so > users can bitch to the owner. > - Tor exits? Well, they're volunteer paid diversity, so which is > more valuable to you? The IF's above, or TCP truth at > potential cost to diversity? > > I prefer TCP truth, but if I was a constrained operator > I'd do my best research into setting up a quality cache. > Provided caching images of ill repute on disk were not > an overriding concern. > <snip> I can imagine two strategies to avoid caching images on-disk: 1. Use an in-memory cache 2. Don't cache images While these strategies might not technically/legally offer much more protection (IANAL): 1. If the cache disappears as soon as the machine shuts down, it's much harder to prove the possession of anything illegal. (However, the proxy headers, live imaging, or an insecure/subverted server might give away what was being cached.) 2. And if images aren't being cached, while textual material could still be illegal, it's less likely to be specifically targeted by law enforcement. In my opinion, if you use HTTP over the internet, you are essentially consenting to caching, inspection, or worse. And most people know that by now. And if you use HTTP over Tor, you should be much more aware of this. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

1 0

Re: [tor-relays] Simulate High Tor Load
by teor 11 Jan '15

11 Jan '15

Hi, chutney can be used to setup a large test tor network running solely on a single machine, with no outside network access required. The tor/src/test/test-network.sh script will configure an entire test tor network and verify connectivity from each client through the network. This works best with tor 0.2.6.2-alpha due to some bootstrap speed improvements, although with larger networks you may need to use --delay to increase the bootstrap time. I suggest you start with --flavour basic-min, and move through the sizes to --flavour basic-100 (my machine can barely run basic-100). You can also manually modify the amount of random data sent while verifying connectivity (look for "Octets" in chutney's TorNet.py). It would be nice if this amount was configurable (patches gladly accepted). It would also be nice if these connections were done in parallel, but I don't think that's the case (clarification or patches gladly accepted). teor > Date: Sun, 11 Jan 2015 14:18:01 +0100 > From: webmaster <webmaster(a)defcon-cc.dyndns.org> > > Hi Julien, > > thats exactly the setup I'm actually using. I use my relay as a client. > From my point of view it seems that the relay is used as a entry point > (without guard flag) in this constellation (correct me if I'm wrong). > > Torsocks could solve my problem. > > My goal is to examine the influence of a high traffic load on my relay > to perhaps adjust my server settings (number of open file descriptors, > ...). > > > >> Am 11.01.2015 um 13:05 schrieb Julien ROBIN: >> Hi, >> >> If you are on a dedicated high Bandwidth server you can maybe use your relay as client, an idea could be to open a lot of "wget" commands. >> >> sudo apt-get install torsocks >> usewithtor wget URL >> >> But it's not guaranteed that the selected circuits will be super-fast (first reason to open lot of wgets simultaneously) >> >> Of course, doing that you consume some useful bandwidth for users (but if it's quick, after all you're a Tor user like another!) >> >> And it's not totally the same that relaying data as server, since it's using the client part of the tor process (but starting from here, I cannot help you anymore since I don't know what is written in the code ;) >> >> So if anybody have another better idea >> Something that would generate a full customized circuit for example, or reduce the amount of used hop for the test. >> >> It already exists "EntryNodes" and "ExitNodes" commands for your torrc file, but no server can be used as EntryNode if it's not Guard already, and I'm not sure that some "MiddleNodes" command exists. >> >> >> Last things, you can also make you machine's CPU working hard on a lot of threads simultaneously, and watch if Tor is suffering or not (like "too many circuit creation request!" in the log). >> >> Or make some tests with Iperf for high bandwidth load in parallel ("iperf -s" on a fast machine, "ipers -c Ip -t TimeInSeconds -p port -P ParallelsTcpConnexions" on the other machine - this one will send data (chains of 1234567890123...) to the server) >> >> Good luck ! By curiosity, I'm interested also, but I would understand if this kind of easiness in creating bandwidth statistics and degraded path (for analysis, for example) is not really sought by developers. >> >> Best regards, >> Julien ROBIN >> >> >> >> ----- Mail original ----- >> De: "webmaster" <webmaster(a)defcon-cc.dyndns.org> >> ?: tor-relays(a)lists.torproject.org >> Envoy?: Dimanche 11 Janvier 2015 11:59:12 >> Objet: [tor-relays] Simulate High Tor Load >> >> Hey Folks, >> >> is there a common procedure for testing a tor server for a high load? >> >> Thanks in advance >

1 0

Relays not listed
by Felix 11 Jan '15

11 Jan '15

Hi most of my relays are no longer listed on Torstatus* and Consensus**. But they perform like they should. out $E388F7BD196F5195AEF114552585152EA6942329 out $2691AE47D3E1D5702520F2792951927C9FE82C67 out $8d1a618c523a8cc761b7253e96c6d19285c47029 out $05d54acea361a57b16cd461340bd32f39383470e out $1E64DACE137A4A6223E7A4A73060A22ECA46D7B3 out $772C86361E276271665579621815F43311A29DA6 out $A53F5920B86F8190569BDFD59F7818BA73966CC3 out $9FBD26A8EB88126FCEF76205255571E450170949 out $BF4FFC4EE4D56AD6506D6FA96BA9EBD8001744BB in $5B3B9A0EA1DC16F6348C57FCC83BBB43D1013F4A I found Atlas was down between 21:30 ans 01:30 yesterday night. Any ideas ? Cheers, Felix * http: jlve2y45zacpbz6s.onion/index.php ** https: consensus-health.torproject.org/consensus-health.html

3 2

Simulate High Tor Load
by webmaster 11 Jan '15

11 Jan '15

Hey Folks, is there a common procedure for testing a tor server for a high load? Thanks in advance -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+ zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0 lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5 EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk ZRMbezQ= =Med3 -----END PGP PUBLIC KEY BLOCK-----

2 2

Atlas / Globe backend appears to be down
by starlight.2015q1＠binnacle.cx 11 Jan '15

11 Jan '15

Can't pull anything up on either Atlas or Globe.

3 2

Secure secure Shell update protocols
by 0x23 10 Jan '15

10 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey guys, wanna share some current insights regarding secure shell(ssh) on how to harden sys after the German 'Der Spiegel' disclosed documents.h https://stribika.github.io/2015/01/04/secure-secure-shell.html Greet#z - -- -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQIzBAEBCgAdBQJUsD4TFhwweDIzIDxydXNoMjNAZ214Lm5ldD4ACgkQF7zsyb8G YjiPyRAAkta8iRmORYJeKdLUzo9Bi4arEqCIjMNaOaZmn+2fTNv3j3nqeyC+r+Sy rLEVXOW5Zcb4QdcSSsU3l3oZCx2bc7hKC4ysCRnEfT03XSwc/acGVHd3FDePF2GB ypqOIJjwZ0T/11DZfJo2zfk18G6FVEKWGa1WTjKkpylvyHLE5Y3FlrqvhJMhql37 Vm4SpF4HncXgJl8njJeQayLr10O/Kcq+FI4d+jHarByU6p9Ry4Lx6EjflfQirb+T UJtZi5mmZyPI01RUnu+HM3aEvRetEj4IpPdjdsA8NESKOBlOxX39cPtPz6HOPiKD BDymO1ZrXfzohjnMMj3FVHZOqS79wc4wq0M7PKPSsxuWL7gI/HepO724Wm6q62ml nPnLRoUc9Gpq9bhRZmRshMjU1zs3eDYR54WnRPf1TQy4JRpThbeHlsIGHQQc9yVD BdP7U5zCuVgVPmn9uKho/6rpxSigMSpdsYSB4UF0n056yiQ1JolRPpOKPYkVSp6U 3xfbWNBdQ0aFD3TuXrj19SYe9KhSE7N07mDgU2KngXz/oVyMXxEKuVxtxTF00k/g JKg+AcwNvjD5LOa27N6bePR+tPHydnvlWkonBwsuaYBvPZvWbocZFuMyRPjmWzh4 PuAmja/SiSiFbQzSqlv53BY2krCMdbZb93i3xQTqgDiA5JmOdd4= =IZOD -----END PGP SIGNATURE-----

2 2

please put jego00X relays in a "family"
by Nusenu 10 Jan '15

10 Jan '15

Dear Tor relay operator, thanks for running your relays with such a great diversity (not two relays in the same network). Please be so kind to put all your relays [1] into a so called family to tell Tor clients that these relays are managed by one entity and should not be used toghther in one circuit. thanks! Nusenu The relevant configuration option is: > MyFamily node,node,… > > Declare that this Tor server is controlled or administered by a group > or organization identical or similar to that of the other servers, > defined by their identity fingerprints. When two servers both declare > that they are in the same 'family', Tor clients will not use them in > the same circuit. (Each server only needs to list the other servers > in its family; it doesn’t need to list itself, but it won’t hurt.) Do > not list any bridge relay as it would compromise its concealment. > When listing a node, it’s better to list it by fingerprint than by > nickname: fingerprints are more reliable. [1] https://atlas.torproject.org/#search/jego

1 0

Tor in Spain
by Torizen 09 Jan '15

09 Jan '15

Hello, I've been running a non-exit relay on a EDIS VPS located in Spain for 5 months. Yesterday, without warning, I received an email because apparently I was abussing the network and my VPS was suspended. I was asked to reduce the amount of traffic Tor is allowed to use and after that I received another email where they claimed running a Tor relay, or any other "anonymization software", is now forbidden. I'm from Spain and this is the first time I've heard of this. Does anyone know if this is true? Torizen.

7 13

Re: [tor-relays] new VPS bridge bandwidth under-reported
by starlight.2015q1＠binnacle.cx 09 Jan '15

09 Jan '15

> Bridge relays . . . Isis, Thank you very much for your description of how it works and the references to the specifications. More and more I've come to realize one should start there. >> It just popped to 700KB, presumably because >> I used it to browse and then download >> the TBB bundle as a test. >I believe that client activity shouldn't >effect your reported bandwidth (but >I'm not entirely sure, actually). Just tested it again the same way except using obfs3 and the self-reported bandwidth from getinfo dir/server/authority shot from 60 Kbytes/sec to 950 Kbytes/sec instantantaneously. Will show up in Atlas shortly I presume. Based on the description you provided this seems sane enough. Thanks again!

1 0

Re: [tor-relays] new VPS bridge bandwidth under-reported
by starlight.2015q1＠binnacle.cx 09 Jan '15

09 Jan '15

Whoa wow. . . It just popped to 700KB, presumably because I used it for to browse and then download the TBB bundle as a test. So I guess that means the bandwidth measurement for a bridge is strictly passive? Presumably that also means that it is not used as a criteria for dissemination?

3 11

badexit 03F84EA2E09CF427A519C65479DC0BF0D72886A6
by grarpamp 08 Jan '15

08 Jan '15

router Tansam 79.143.87.234 443 0 0 03F84EA2E09CF427A519C65479DC0BF0D72886A6 Appears to be having trouble with, or is doing something with, http versions of https en.wikipedia.org articles. They're either blank or stripped of framework.

1 0

missing pluggable transport
by qq1693129601 08 Jan '15

08 Jan '15

When open tor-browser, it says Tor failed to establish a Tor network connection. Connecting to a relay directory failed (missing pluggable transport). The log is below, could anyone help? ----- 01/06/2015 15:03:35.786 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 01/06/2015 15:03:35.786 [NOTICE] Opening Socks listener on 127.0.0.1:9150 01/06/2015 15:03:36.711 [WARN] The communication stream of managed proxy './TorBrowser/Tor/PluggableTransports/fteproxy.bin' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. 01/06/2015 15:03:36.711 [NOTICE] Failed to terminate process with PID '30230' ('Success'). 01/06/2015 15:03:37.711 [NOTICE] Bootstrapped 5%: Connecting to directory server 01/06/2015 15:03:37.711 [WARN] We were supposed to connect to bridge '[2001:49f0:d002:1::2]:80' using pluggable transport 'fte', but we can't find a pluggable transport proxy supporting 'fte'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running. 01/06/2015 15:03:37.712 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 1; recommendation warn) 01/06/2015 15:03:39.270 [WARN] We were supposed to connect to bridge '[2001:49f0:d00a:1::c]:80' using pluggable transport 'fte', but we can't find a pluggable transport proxy supporting 'fte'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running. 01/06/2015 15:03:39.270 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 2; recommendation warn)

2 1

Exit Node / iptables / massive attempts on DPT 8118 ?
by rush23＠gmx.net 07 Jan '15

07 Jan '15

5 16

Re: [tor-relays] Help - My relay consensus has been stripped back to 20
by bigbudtor＠Safe-mail.net 06 Jan '15

06 Jan '15

Argh - yes you are right. It was fine again last night and yes it is back down to 20. What the hell is going on? I find it quite troubling that nobody seems to know (or wants to say) why these relays are getting disabled. cheers BB -------- Original Message -------- From: tor-relays-request(a)lists.torproject.org Apparently from: tor-relays-bounces(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Subject: tor-relays Digest, Vol 48, Issue 21 Date: Tue, 06 Jan 2015 12:00:02 +0000 >Yours and mine are back to 20. >On 05.01.2015 03:37 PM, bigbudtor at Safe-mail.net wrote: >> -------- Original Message -------- >> From: tor-relays-request at lists.torproject.org >> Apparently from: tor-relays-bounces at lists.torproject.org >> To: tor-relays at lists.torproject.org >> Subject: tor-relays Digest, Vol 48, Issue 15 >> Date: Mon, 05 Jan 2015 11:05:49 +0000 >> >> >>> Message: 3 >>> Date: Mon, 05 Jan 2015 11:36:59 +0100 >>> From: Network Operations Center <noc at schokomil.ch> >>> To: tor-relays at lists.torproject.org >>> Subject: Re: [tor-relays] Help - My relay consensus has been stripped >>> back to 20 >>> Message-ID: <84a966b4ad0f4d6a230d7b51f1d6b42f at schokomil.ch> >>> Content-Type: text/plain; charset=UTF-8; format=flowed >>> >>> Mine just jumped to 18,000, again I'd like to stress that I have not >>> changed anything in my torrc: >>> >>> https://atlas.torproject.org/#details/3D7E274A87D9A89AF064C13D1EE4CA1F184F2… >> >> Yup, me too. Seems to be back thankfully. >> >> Would love to know why though.... >> >> best >> >> BB >> _______________________________________________ >> tor-relays mailing list >> tor-relays at lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Help - My relay consensus has been stripped back to 20
by bigbudtor＠Safe-mail.net 06 Jan '15

06 Jan '15

-------- Original Message -------- From: tor-relays-request(a)lists.torproject.org Apparently from: tor-relays-bounces(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Subject: tor-relays Digest, Vol 48, Issue 15 Date: Mon, 05 Jan 2015 11:05:49 +0000 > Message: 3 > Date: Mon, 05 Jan 2015 11:36:59 +0100 > From: Network Operations Center <noc(a)schokomil.ch> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Help - My relay consensus has been stripped > back to 20 > Message-ID: <84a966b4ad0f4d6a230d7b51f1d6b42f(a)schokomil.ch> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Mine just jumped to 18,000, again I'd like to stress that I have not > changed anything in my torrc: > > https://atlas.torproject.org/#details/3D7E274A87D9A89AF064C13D1EE4CA1F184F2… Yup, me too. Seems to be back thankfully. Would love to know why though.... best BB

2 1

Re: [tor-relays] how to monitor traffick through a bridge
by starlight.2015q1＠binnacle.cx 06 Jan '15

06 Jan '15

>Thank you very much for all the precious advice. >I am running tor on linux. I second the suggestion of applying 'iptables' to collecting traffic statistics. Lot of ways to go about it but here's something similar to the approach I'm using. By having separate entries for established and new connections on the input side, one can see both how much traffic is arriving and how many connection requests are arriving. Of if your node is attacked, the second new-connection catcher will show huge volumes of DOS traffic. Also note the separate counters for ssh and OR port traffic, so you can distinguish maintenance and utilization activity. Feel free to change all the port assignments as suits you, even the ssh one. The example uses defaults for illustration. Is recommended that the OR port be assigned randomly in order to make discovery via 'zmap' more difficult. 22 ssh 9001 OR 443 obfs3 80 fte 587 scramblesuit 993 obfs4 The 'iptables' file loses the .txt extension and CR characters (addded for easier MUA clicking) and generally goes in /etc/sysconfig/iptables. Also attaching an example statistics display command and output, and a batch job for collecting the information automatically every day.

1 0

how to monitor traffick through a bridge
by mattia 05 Jan '15

05 Jan '15

Hi, I would like to know how one can monitor traffic that goes through a bridge. I have set one up and would like to know whether it is being used or not, and how much. Thanks!

5 6

Fwd: [tor-talk] please advise on renting a gigabit capable dedicated server
by Libertas 05 Jan '15

05 Jan '15

In case there are people that don't subscribe to both. -------- Forwarded Message -------- Subject: [tor-talk] please advise on renting a gigabit capable dedicated server Date: Fri, 2 Jan 2015 19:31:05 -0600 From: Christopher Yeager <jager(a)farmhouseproject.org> Reply-To: tor-talk(a)lists.torproject.org To: tor-talk(a)lists.torproject.org Hi tor users, my coworkers and I are considering getting together to run a gigabit exit relay and are curious if you all have advice as to the best place to go shopping for a server with 1gbps dedicated bandwidth in a location that is helpful to the network. Someone on irc pointed me to this list, but I'm happy to ask on another if it would be more appropriate. Thanks in advance! -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

4 4

new VPS bridge bandwidth under-reported
by starlight.2015q1＠binnacle.cx 05 Jan '15

05 Jan '15

Hello, Just setup a new bridge running 0.2.6.1-alpha and it's working fine. The bridge is running in a Linux container VPS and appears to have an iptables traffic-shaped bandwidth limit of 400KB. Can browse and download files through it with decent performance using obfs4. However self-measurement of bandwidth, after starting at around 200Kbytes has steadily declined until now its showing 8KB and has lost the "fast" flag. At this point the bridge has yet to attract any traffic other then my testing usage--but it works just fine nevertheless. I suspect that latency for small transfers is fairly bad (in the sense of milliseconds, rather than seconds) and that this may be distorting bandwidth metrics. Also the number of bytes transferred is close to zero, which does not seem likely to help the situation. Should I be concerned about it? Anything anyone can recommend to correct it aside from looking another VPS provider? Does the advertised bandwidth have much effect on whether the bridge will be disseminated by the bridge database system? No "stable" flag yet, but not enough time has passed for this to happen. Thanks

3 4

Re: [tor-relays] Help - My relay consensus has been stripped back to 20
by bigbudtor＠Safe-mail.net 05 Jan '15

05 Jan '15

> > Message: 3 > Date: Sat, 03 Jan 2015 02:30:55 +0100 > From: Sebastian Urbach <sebastian(a)urbach.org> > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] Help - My relay consensus has been stripped > back to 20 > Message-ID: > <14aad6973e8.27ae.e04ee758f2dadc1889b5b423dda555f9(a)urbach.org> > Content-Type: text/plain; charset="UTF-8"; format=flowed > > On January 3, 2015 2:03:33 AM bigbudtor(a)Safe-mail.net wrote: > > Hi, > > > As i recall there was a mail from Giovanny a few days ago and he reported > his relay being down. But he had log file entries like: > > [warn] http status 400 ("Authdir is rejecting routers in this range.") > response from dirserver '128.31.0.39:9131'. > > Any of those in your log ? > No I don't see anything resembling that, although I am seeing these events messages in the logs every couple of hours: Dec 30 07:52:28.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 09:55:29.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 11:52:24.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 13:53:23.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 15:52:20.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 16:06:34.000 [info] router_upload_dir_desc_to_dirservers(): Uploading relay descriptor to directory authorities Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 3891) Dec 30 17:52:19.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 19:53:18.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 21:39:02.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 30 23:33:58.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 31 01:32:55.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 31 02:52:13.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. Dec 31 05:05:32.000 [info] router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again. I don't appear to have any routing issues, resolution issues or similar but don't have logs old enough to see if this is an unusual log event or not, it may be completely unrelated. As it stands I am afraid that there doesn't seem to be any real alternative other than decommissioning this exit relay. It is costing money and doing nobody any good right now.

2 2

Jump in brute force complaints
by Kura 05 Jan '15

05 Jan '15

I've noticed a rather large jump in abuse emails from admits about brute force attempts coming from my exit nodes. I've had a handful of these in past, as you'd expect but now they are arriving multiple times a day, some automated emails, some not. Has anyone else noticed a jump in abuse complaints? Curious as to whether it's a spike in the network being used for abuse, more admits reading logs or just my luck. -- Kura t: @kuramanga [https://twitter.com/kuramanga] w: https://kura.io/ [https://kura.io/] g: @kura [http://git.io/kura]

7 7

Re: [tor-relays] tor-relays Digest, Vol 48, Issue 12
by bigbudtor＠Safe-mail.net 04 Jan '15

04 Jan '15

-------- Original Message -------- On January 4, 2015 11:14:17 PM bigbudtor at Safe-mail.net wrote: > Hi, > > No dirservers reachable sounds like a pretty good reason why your not > getting anything anymore. Did you try to reach any of them manually ? That > sounds to me like there is either something wrong with the connectivity or > it is massive blocking. I can resolve the hostnames and then connect to the dir port on each of the directory authority servers manually using netcat. The relay is clearly still up and holding connections (down to around 80 inbound now, a few outbound and a small number of exit connections).

1 0

Re: [tor-relays] Help - My relay consensus has been stripped back to 20
by Sebastian Urbach 04 Jan '15

04 Jan '15

On January 4, 2015 11:14:17 PM bigbudtor(a)Safe-mail.net wrote: Hi, > > > > Message: 3 > > Date: Sat, 03 Jan 2015 02:30:55 +0100 > > From: Sebastian Urbach <sebastian(a)urbach.org> > > To: <tor-relays(a)lists.torproject.org> > > Subject: Re: [tor-relays] Help - My relay consensus has been stripped > > backto 20 > > Message-ID: > > <14aad6973e8.27ae.e04ee758f2dadc1889b5b423dda555f9(a)urbach.org> > > Content-Type: text/plain; charset="UTF-8"; format=flowed > > > > On January 3, 2015 2:03:33 AM bigbudtor(a)Safe-mail.net wrote: > > > > Hi, > > > > > > As i recall there was a mail from Giovanny a few days ago and he reported > > his relay being down. But he had log file entries like: > > > > [warn] http status 400 ("Authdir is rejecting routers in this range.") > > response from dirserver '128.31.0.39:9131'. > > > > Any of those in your log ? > > > > No I don't see anything resembling that, although I am seeing these events > messages in the logs every couple of hours: > > Dec 30 07:52:28.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 09:55:29.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 11:52:24.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 13:53:23.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 15:52:20.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 16:06:34.000 [info] router_upload_dir_desc_to_dirservers(): > Uploading relay descriptor to directory authorities > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 17:52:19.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 19:53:18.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 21:39:02.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 23:33:58.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 31 01:32:55.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 31 02:52:13.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 31 05:05:32.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > > I don't appear to have any routing issues, resolution issues or similar but > don't have logs old enough to see if this is an unusual log event or not, > it may be completely unrelated. > > As it stands I am afraid that there doesn't seem to be any real alternative > other than decommissioning this exit relay. It is costing money and doing > nobody any good right now. No dirservers reachable sounds like a pretty good reason why your not getting anything anymore. Did you try to reach any of them manually ? That sounds to me like there is either something wrong with the connectivity or it is massive blocking. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

odd list of connections
by TOR Zone 04 Jan '15

04 Jan '15

1 0

Someone broke the tor-relay speed record?
by Justaguy 04 Jan '15

04 Jan '15

https://globe.thecthulhu.com/#/relay/F528DED21EACD2E4E9301EC0AABD370EDCAD2C… Someone just got 149.08 MB/s on a non-exit relay. This is amazing! Would you mind saying what kind of hardware you use for this? Ipredator used https://ipredator.se/guide/torserver to get to 101MB/s. So your setup should be even more extreme. -- PGP fingerprint: 8516 5FFC 011A 6465 D042 6AC1 D719 1F41 B7CE EDFF OTR fingerprint OFTC: FF6D1AC2 13F38B15 EDB21522 D3530A6F 6EE01996 OTR fingerprint freenode: 293FAFD3 1155A465 C5B77015 B65E8AEC 63A1AF21 Full PGP public key: https://justaguy.pw

6 11

Location of Tor relays being incorrectly reported in Atlas
by Joshua Lee Tucker 03 Jan '15

03 Jan '15

Hi guys, Two of my Tor relays are being reported as being located within the USA within Atlas; these nodes are actually located within London, UK - the location is correctly identified when using an IP->Location service. I’m just wondering why this would occur? The two IP addresses are: 178.62.75.82 178.62.77.54 Thanks guys, Joshua Lee Tucker

7 6

Re: [tor-relays] HardwareAccel: Current proper use???
by Sebastian Urbach 03 Jan '15

03 Jan '15

On January 3, 2015 10:41:42 AM usprey <usprey(a)gmail.com> wrote: Hi usprey, > Summary: > The documentation is still somewhat vague on the best use of the > "HardwareAccel" option. > > > *HardwareAccel* *0*|*1* The docu is not exactly a high-performance howto :-) > > > > If non-zero, try to use built-in (static) crypto hardware acceleration > > when available. (Default: 0) > > > I could not find a definitive answer in the archives or in > https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1 > . > > https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims > no intervention is needed in regards of aes-ni accelaration, but I would > like to add an explanation or source to this recommendation. > > Question_1: > If my CPU supports and have loaded aesni_intel on linux with OpenSSL is > 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it? You don't have to change anything with 1.0.1.j-1, leave the default. > > Question_2: > What does "*built-in (static) crypto hardware acceleration*" refer to? > Dedicated hardware, CPU-support or...? It specifically means that you have the aes_ni cpu capabilities / flag. I have seen this flag on dedicated systems and also on vps systems as well. If the cpu / bios provides the flag and all other requirements are met (as stated in the torservers.net docu) you can use that feature on any system. I would very much appreciate it if you would switch to text mail format, thanks. Thank you very much for running a relay ! > > Best regards > > > > ---------- > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 4

High speed exit question
by Kura 03 Jan '15

03 Jan '15

Hey guys, I recently decided to get myself an 8 core, 16 GB RAM machine to use for running an exit relay and was wondering, Tor only works on one core, even setting NumCPUs to 2 doesn't do a whole lot so, how is it even possible to get more than maybe, 300Mbps or so from one relay? Maybe I'm missing something but, running multiple Tor processes is just going to have multiple relays with different OR and Dir ports for each, right? -- Kura t: @kuramanga [https://twitter.com/kuramanga] w: https://kura.io/ [https://kura.io/] g: @kura [http://git.io/kura]

6 8

HardwareAccel: Current proper use???
by usprey 03 Jan '15

03 Jan '15

Summary: The documentation is still somewhat vague on the best use of the "HardwareAccel" option. > *HardwareAccel* *0*|*1* > > If non-zero, try to use built-in (static) crypto hardware acceleration > when available. (Default: 0) > I could not find a definitive answer in the archives or in https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1 . https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims no intervention is needed in regards of aes-ni accelaration, but I would like to add an explanation or source to this recommendation. Question_1: If my CPU supports and have loaded aesni_intel on linux with OpenSSL is 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it? Question_2: What does "*built-in (static) crypto hardware acceleration*" refer to? Dedicated hardware, CPU-support or...? Best regards

2 2

Re: [tor-relays] Reduced number of HSDir's
by SiNA Rabbani 02 Jan '15

02 Jan '15

There was a new line added to authority director configs, which was a response to the recent Sybil attack [1]: MinUptimeHidServDirectoryV2 96 hours That's only 4 days, I wonder if anything else has changed. --SiNA [1] https://lists.torproject.org/pipermail/tor-consensus-health/2014-December/0… "Be the change that you wish to see in the world." - Mahatma Gandhi ----- On Jan 2, 2015, at 2:51 PM, Sebastian G. <bastik.tor> bastik.tor(a)googlemail.com wrote: > 02.01.2015, 19:47 Kura: >> I think something must have happened, I restarted half a dozen or so >> of my relays over a week ago and none of them have been given the >> HSDir flag, which if I remember rightly is a 21 hour flag? I may be >> mistaken but, I would have expected that flag to be back with over a >> week of uptime. > > It used to be a 25 hour flag. 1 day plus an additional hour. > > I think (yes, that says I don't know) the period being longer than 24 > hours had something to do with an attack to get relays under adversary > control in the right position to become a HSDir for some > hidden-services. If one pays for a relays by days an additional hour is > an additional day for an attacker. > > I may have missed something, but maybe it was raised. > > I do remember that changes to Guards took place, like requiring them to > have more bandwidth and to reducing the number of Guards clients would > use. This was due to research. > > Regards, > Sebastian > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Help - My relay consensus has been stripped back to 20
by bigbudtor＠Safe-mail.net 02 Jan '15

02 Jan '15

Thanks Sebastian, That explains the loss of guard status back in August at least. I totally missed that announcement. Back to the main issue, it does look like one or two others at least are having this problem. Is it simply as a result of being in a Lizard-blacklisted netblock? Bigbud is in 85.119.0.0/16. Is the current Lizard-blacklist published or is it only known to the directory authorities? thanks BB > Hi, > Found the snippet with the changes for the guards: > Tor Weekly News, 30th of July 2014 > Once directory authorities have upgraded, they will “assign the Guard flag > to the fastest 25% of the network”. Some experiments showed that “for the > current network, this results in about 1100 guards, down from 2500.” > > -- > Sincerely yours / Sincères salutations > > Sebastian Urbach

2 1

Help - My relay consensus has been stripped back to 20
by Sebastian Urbach 02 Jan '15

02 Jan '15

Hi, Found the snippet with the changes for the guards: Tor Weekly News, 30th of July 2014 Once directory authorities have upgraded, they will “assign the Guard flag to the fastest 25% of the network”. Some experiments showed that “for the current network, this results in about 1100 guards, down from 2500.” -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Help - My relay consensus has been stripped back to 20
by bigbudtor＠Safe-mail.net 02 Jan '15

02 Jan '15

On the 29th December one of our relays, bigbud (6911888F83565892FE23F1B03EB501D80E1E8780) which had a consensus of 630+ and had been running for nearly 18 months (100 days uptime running 2.5.8) suddenly started receiving much less traffic. I have seen a gradual reduction in traffic over the course of the last year but on the 29th the drop off was very significant and I saw in Atlas that the consensus is dropped to 20. When I look at the consensus files it shows that bigbud has a consensus of 20 and that Unmeasured was set to 1. Any ideas please? I upgraded Tor to 2.5.10 after I noticed the consensus drop. Is this something to do with the Lizard new relay flood or something or is there an actual problem with the relay? On a related note the relay lost guard status too a few months ago and I couldn't see why that would be.

3 2

Re: [tor-relays] sudden drop
by Spencer Rhodes 02 Jan '15

02 Jan '15

Not sure if related, but I noticed today one of my exit relays was not operating properly. Turned out the bind server was not resolving properly. I turned off dnssec and it started working again... On January 2, 2015 6:45:30 PM EST, tor-relays-request(a)lists.torproject.org wrote: >Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-relays digest..." > > >------------------------------------------------------------------------ > >Today's Topics: > > 1. Reduced number of HSDir's (Sebastian Urbach) > 2. Re: Reduced number of HSDir's (Austin Bentley) > 3. Re: Reduced number of HSDir's (Kura) > 4. Re: Reduced number of HSDir's (Sebastian G. <bastik.tor>) > 5. Help - My relay consensus has been stripped back to 20 > (bigbudtor(a)Safe-mail.net) > 6. Re: Help - My relay consensus has been stripped back to 20 (s7r) > > >------------------------------------------------------------------------ > >From: Sebastian Urbach <sebastian(a)urbach.org> >To: tor-relays(a)lists.torproject.org >Sent: Fri Jan 02 12:25:06 EST 2015 >Subject: [tor-relays] Reduced number of HSDir's > >Hi, > >https://metrics.torproject.org shows a big nose dive recently regarding >the >number of HSDir's. Did i miss anything relevant in the last days ? That > >seem to be the reason why i see increasing download numbers on my >system. > >Thanks for any lind of info. >-- >Sincerely yours / Sincères salutations > >Sebastian Urbach > >----------------------------------------- >Definition of Tor: >10% luck, 20% skill, 15% concentrated >power of will, 5% pleasure, 50% pain and >100% reason to remember the name! >----------------------------------------- > > > > > >------------------------------------------------------------------------ > >From: Austin Bentley <ab6d9(a)mst.edu> >To: tor-relays(a)lists.torproject.org >Sent: Fri Jan 02 13:29:33 EST 2015 >Subject: Re: [tor-relays] Reduced number of HSDir's > >No clue. I wonder if there's some backlash from a anti-attack mechanism >of >some sort? There was a few attempted attacks against the Tor network, >but >it wasn't anything worth discussing. Check out the post on the 31st >from >blog.torproject.org. > >On Fri, Jan 2, 2015 at 11:25 AM, Sebastian Urbach ><sebastian(a)urbach.org> >wrote: > >> Hi, >> >> https://metrics.torproject.org shows a big nose dive recently >regarding >> the number of HSDir's. Did i miss anything relevant in the last days >? That >> seem to be the reason why i see increasing download numbers on my >system. >> >> Thanks for any lind of info. >> -- >> Sincerely yours / Sincères salutations >> >> Sebastian Urbach >> >> ----------------------------------------- >> Definition of Tor: >> 10% luck, 20% skill, 15% concentrated >> power of will, 5% pleasure, 50% pain and >> 100% reason to remember the name! >> ----------------------------------------- >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > >------------------------------------------------------------------------ > >From: Kura <kura(a)kura.io> >To: tor-relays(a)lists.torproject.org >Sent: Fri Jan 02 13:47:51 EST 2015 >Subject: Re: [tor-relays] Reduced number of HSDir's > >I think something must have happened, I restarted half a dozen or so of >my relays over a week ago and none of them have been given the >HSDir flag, which if I remember rightly is a 21 hour flag? I may be >mistaken but, I would have expected that flag to be back with over a >week of uptime. > > >-- >Kura > >t: @kuramanga [https://twitter.com/kuramanga] >w: https://kura.io/ [https://kura.io/] >g: @kura [http://git.io/kura] >On 02/01/2015 18:30:00, Austin Bentley <ab6d9(a)mst.edu> wrote: >No clue. I wonder if there's some backlash from a anti-attack mechanism >of some sort? There was a few attempted attacks against the Tor >network, but it wasn't anything worth discussing. Check out the post on >the 31st from blog.torproject.org [http://blog.torproject.org] > > >On Fri, Jan 2, 2015 at 11:25 AM, Sebastian Urbach <sebastian(a)urbach.org >[mailto:sebastian@urbach.org]> wrote: > >Hi, > >https://metrics.torproject.org [https://metrics.torproject.org] shows a >big nose dive recently regarding the number of HSDir's. Did i miss >anything relevant in the last days ? That seem to be the reason why i >see increasing download numbers on my system. > >Thanks for any lind of info. >-- >Sincerely yours / Sincères salutations > >Sebastian Urbach > >----------------------------------------- >Definition of Tor: >10% luck, 20% skill, 15% concentrated >power of will, 5% pleasure, 50% pain and >100% reason to remember the name! >----------------------------------------- > > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >[mailto:tor-relays@lists.torproject.org] >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >[https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays] > > >_______________________________________________ tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >------------------------------------------------------------------------ > >From: "Sebastian G. <bastik.tor>" <bastik.tor(a)googlemail.com> >To: tor-relays(a)lists.torproject.org >Sent: Fri Jan 02 14:51:26 EST 2015 >Subject: Re: [tor-relays] Reduced number of HSDir's > >02.01.2015, 19:47 Kura: >> I think something must have happened, I restarted half a dozen or so >> of my relays over a week ago and none of them have been given the >> HSDir flag, which if I remember rightly is a 21 hour flag? I may be >> mistaken but, I would have expected that flag to be back with over a >> week of uptime. > >It used to be a 25 hour flag. 1 day plus an additional hour. > >I think (yes, that says I don't know) the period being longer than 24 >hours had something to do with an attack to get relays under adversary >control in the right position to become a HSDir for some >hidden-services. If one pays for a relays by days an additional hour is >an additional day for an attacker. > >I may have missed something, but maybe it was raised. > >I do remember that changes to Guards took place, like requiring them to >have more bandwidth and to reducing the number of Guards clients would >use. This was due to research. > >Regards, >Sebastian > > > >------------------------------------------------------------------------ > >From: bigbudtor(a)Safe-mail.net >To: tor-relays(a)lists.torproject.org >Sent: Fri Jan 02 18:28:48 EST 2015 >Subject: [tor-relays] Help - My relay consensus has been stripped back >to 20 > >On the 29th December one of our relays, bigbud >(6911888F83565892FE23F1B03EB501D80E1E8780) which had a consensus of >630+ and had been running for nearly 18 months (100 days uptime running >2.5.8) suddenly started receiving much less traffic. > >I have seen a gradual reduction in traffic over the course of the last >year but on the 29th the drop off was very significant and I saw in >Atlas that the consensus is dropped to 20. When I look at the consensus >files it shows that bigbud has a consensus of 20 and that Unmeasured >was set to 1. > >Any ideas please? I upgraded Tor to 2.5.10 after I noticed the >consensus drop. Is this something to do with the Lizard new relay flood >or something or is there an actual problem with the relay? > >On a related note the relay lost guard status too a few months ago and >I couldn't see why that would be. > > > >------------------------------------------------------------------------ > >From: s7r <s7r(a)sky-ip.org> >To: tor-relays(a)lists.torproject.org >Sent: Fri Jan 02 18:39:52 EST 2015 >Subject: Re: [tor-relays] Help - My relay consensus has been stripped >back to 20 > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >This was reported yesterday 01.01.2015 in IRC too, for this relay: > >3D7E274A87D9A89AF064C13D1EE4CA1F184F2600 > >The same it was pushing good amounts of traffic and the consensus >weight dropped to 20 with no modifications made to the Tor config file >or anything. You are the 3rd person who reports this, seams like worth >investigating further. > >I can see both of them are exits, but doubt this has anything to do >with it. > >Could it be a measurement problem from the bandwidth authorities? Why >would it happen only to very few relays in this case? > >On 1/3/2015 1:28 AM, bigbudtor(a)Safe-mail.net wrote: >> On the 29th December one of our relays, bigbud >> (6911888F83565892FE23F1B03EB501D80E1E8780) which had a consensus of >> 630+ and had been running for nearly 18 months (100 days uptime >> running 2.5.8) suddenly started receiving much less traffic. >> >> I have seen a gradual reduction in traffic over the course of the >> last year but on the 29th the drop off was very significant and I >> saw in Atlas that the consensus is dropped to 20. When I look at >> the consensus files it shows that bigbud has a consensus of 20 and >> that Unmeasured was set to 1. >> >> Any ideas please? I upgraded Tor to 2.5.10 after I noticed the >> consensus drop. Is this something to do with the Lizard new relay >> flood or something or is there an actual problem with the relay? >> >> On a related note the relay lost guard status too a few months ago >> and I couldn't see why that would be. >> _______________________________________________ tor-relays mailing >> list tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.22 (MingW32) > >iQEcBAEBAgAGBQJUpyxIAAoJEIN/pSyBJlsRB6MH+wWzDQPlhf+H4KWkoX9J6jhc >GQbL3+YmmZP1Eh941hnE6zaHpk5OUZiDarovBxSdL0FPEyHWlvLJIsFR6VXmfq2s >RB4hId21mKR5HQLNy/at6KP4Xs7dv3Qyid/KCZK3qH82HtJ9Yt9lA6yNTT8uLWmV >zIr1SKAMltBiIVrBWZaNGtqy5NVrGiF3yx2VYuHT7ZORL1l8BVjvG2I9d+/n2n7r >3RdEUKXSeFp/UnLlN5M9ZhHEdQLkioKfUisnkHdPKu7LTvWlVIONCm0t5lHo62xh >MUmbBP+lrWMfmQE8sJaTgmlJKq26Gb+JtG7uXV8k+XOfDokQygnFclJwZtUnKrQ= >=9kZo >-----END PGP SIGNATURE----- > > > >------------------------------------------------------------------------ > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sent from my phone.

1 0

Reduced number of HSDir's
by Sebastian Urbach 02 Jan '15

02 Jan '15

Hi, https://metrics.torproject.org shows a big nose dive recently regarding the number of HSDir's. Did i miss anything relevant in the last days ? That seem to be the reason why i see increasing download numbers on my system. Thanks for any lind of info. -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

4 3

RPM upgrade issue.
by Sascha Siekmann 01 Jan '15

01 Jan '15

Hello, Happy New Year, everone! I've been chasing this down here for the last hour or so and I thought I might as well share it since others might also experience it. I am running https://atlas.torproject.org/#search/plutonium After running yum update this lead to a different fingerprint being generated for the same host. Nov 29 01:09:27 Installed: tor-0.2.5.10-tor.2.rh6_5.i686 Dec 29 19:21:07 Installed: torsocks-2.0.0-2.el6.i686 Dec 29 19:21:10 Updated: tor-0.2.5.10-1.el6.i686 Then, traffic collapsed by going down from <> 8MB/sec to pretty much nothing. I checked the logs and found permission errors. The group for Tor was changed from _tor to toranon, so the permissions were wrong after the rpm was installed. Also, /etc/tor/torrc had this line commented : ## The directory for keeping all the keys/etc. By default, we store ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. DataDirectory /var/lib/tor So it was defaulting to ~tor directory, tor/tor.log-20141230:Dec 30 03:13:01.000 [warn] Default DataDirectory is "~/.tor". This expands to "/.tor", which is probably not what you want. Using "/var/tor" instead [root@plutonium log]# rpm -qa | grep tor torsocks-2.0.0-2.el6.i686 tor-0.2.5.10-1.el6.i686 [root@plutonium log]# Dec 29 17:56:47.000 [notice] Heartbeat: Tor's uptime is 25 days 0:00 hours, with 1885 circuits open. I've sent 6843.34 GB and received 6761.80 GB. Dec 29 17:56:47.000 [notice] Average packaged cell fullness: 97.313% Dec 29 17:56:47.000 [notice] TLS write overhead: 2% Dec 29 17:56:47.000 [notice] Circuit handshake stats since last time: 16007/16007 TAP, 49264/49264 NTor. Dec 29 20:07:10.000 [warn] Couldn't open "/var/lib/tor/cached-microdesc-consensus.tmp" (/var/lib/tor/cached-microdesc-consensus) for writing: Permission denied Dec 29 20:07:10.000 [warn] Couldn't open "/var/lib/tor/cached-microdescs.new" (/var/lib/tor/cached-microdescs.new) for writing: Permission denied Dec 29 20:07:10.000 [warn] Couldn't append to journal in /var/lib/tor/cached-microdescs.new: Permission denied Dec 29 20:07:11.000 [warn] Couldn't open "/var/lib/tor/cached-microdescs.new" (/var/lib/tor/cached-microdescs.new) for writing: Permission denied Dec 29 20:07:11.000 [warn] Couldn't append to journal in /var/lib/tor/cached-microdescs.new: Permission denied Dec 29 20:08:10.000 [warn] Couldn't open "/var/lib/tor/cached-microdescs.new" (/var/lib/tor/cached-microdescs.new) for writing: Permission denied Dec 29 20:08:10.000 [warn] Couldn't append to journal in /var/lib/tor/cached-microdescs.new: Permission denied Dec 29 20:08:10.000 [warn] Couldn't open "/var/lib/tor/cached-microdescs.new" (/var/lib/tor/cached-microdescs.new) for writing: Permission denied Dec 29 20:08:10.000 [warn] Couldn't append to journal in /var/lib/tor/cached-microdescs.new: Permission denied Dec 29 20:09:11.000 [warn] Couldn't open "/var/lib/tor/cached-microdescs.new" (/var/lib/tor/cached-microdescs.new) for writing: Permission denied Dec 29 20:09:11.000 [warn] Couldn't append to journal in /var/lib/tor/cached-microdescs.new: Permission denied Dec 29 20:09:11.000 [warn] Couldn't open "/var/lib/tor/cached-microdescs.new" (/var/lib/tor/cached-microdescs.new) for writing: Permission denied Dec 29 20:09:11.000 [warn] Couldn't append to journal in /var/lib/tor/cached-microdescs.new: Permission denied Dec 29 20:29:31.000 [warn] Couldn't open "/var/lib/tor/cached-consensus.tmp" (/var/lib/tor/cached-consensus) for writing: Permission denied Dec 29 20:29:32.000 [warn] Couldn't open "/var/lib/tor/cached-descriptors.new" (/var/lib/tor/cached-descriptors.new) for writing: Permission denied Dec 29 20:29:32.000 [warn] Unable to store router descriptor I fixed the permissions, but I am seeing this message now that I have not seen before. Jan 1 21:36:02 p15186978 Tor[28986]: Invalid result from curve25519 handshake: 4 Jan 1 21:36:02 p15186978 Tor[28986]: onion_skin_client_handshake failed. Jan 1 21:36:02 p15186978 Tor[28986]: circuit_finish_handshake failed. Jan 1 21:36:02 p15186978 Tor[28986]: connection_edge_process_relay_cell (at origin) failed. Jan 1 21:36:04 p15186978 Tor[28986]: Performing bandwidth self-test...done. Should I be concerned about this message? [root@plutonium etc]# uname -a Linux plutonium 2.6.32-431.el6.i686 #1 SMP Fri Nov 22 00:26:36 UTC 2013 i686 i686 i386 GNU/Linux [root@plutonium etc]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@plutonium etc]# Thanks, Sascha.

2 1

Relay is down
by Giovanny Andres Gongora Granada 01 Jan '15

01 Jan '15

Hi, My relay was up during 4 days, but now it's down. In the log it says: Dec 30 21:19:51.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '128.31.0.39:9131'. Please$ Dec 30 21:19:51.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '208.83.223.34:443'. Pleas$ Dec 30 21:19:51.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '131.188.40.189:80'. Pleas$ Dec 30 21:19:51.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '86.59.21.38:80'. Please c$ What could be happening? I restart it but it says the same on the log. Regards, Gio -- Mozilla Hispano: http://mozilla-hispano.org Mentor en mozilla-hispano.org: Gioyik <https://www.mozilla-hispano.org/documentacion/Usuario:Gioyik> Mozilla Colombia: Miembro en MozillaColombia <http://mozillacolombia.org/our-contributors/> twitter: Gioyik <https://twitter.com/Gioyik> Blog: gioyik.wordpress.com irc: gioyik

8 11