- tor-relays - lists.torproject.org

[warn] channelpadding_ and [warn] assign_
by Felix 03 Jul '17

03 Jul '17

Hi everybody On 3.1.3a there are quiet some log entries like 10 per day and relay, more cicuits - more entries: [warn] channelpadding_compute_time_until_pad_for_netflow: Bug: Channel padding timeout scheduled 212ms in the past. Did the monotonic clock just jump? (on Tor 0.3.1.3-alpha dc47d936d47ffc25) and [warn] assign_to_cpuworker failed. Ignoring. Seems without impact to performance. I just wonder. Switching to 3.1.4a might fix it ? 3.0.8 doesn't show it. [] Tor 0.3.1.3-alpha (git-dc47d936d47ffc25) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.4.3, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.2.0. -- Cheers, Felix

3 2

Reminder: Support for 0.2.4, 0.2.6, and 0.2.7 will end on 1 August 2017
by Nick Mathewson 03 Jul '17

03 Jul '17

Hi! This is a reminder that we will not be making new releases for the 0.2.4, 0.2.6, or 0.2.7 release series after 1 August 2017. If you are running one of those series, please make a plan to upgrade some time before then! 0.2.5 will still be supported until 1 May 2018. 0.2.9 support will continue until 1 Jan 2020 -- use that if you need a release that will be supported long-term. Versions 0.2.3 and earlier are not supported at all. Support for other releases (0.3.1 and 0.3.0) will continue according to the schedule at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… . I'll send out another message like this in early July. peace, -- Nick

1 1

Bad exit node?
by tschador＠posteo.de 02 Jul '17

02 Jul '17

Today, on https://www.youtube.com I got: "An error occurred during a connection to www.youtube.com. Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT" (Browser Firefox) With another browser (Chromium) same problem - no connect. The exit node was 163.172.212.115 (https://check.torproject.org) After a while, with another exit node, no problem anymore. Temporary fault or bad exit node?

2 1

torproject debian alpha packages discontinued?
by nusenu 02 Jul '17

02 Jul '17

Hi, if you have any insides on whether there will be tor 0.3.1.x-alpha debian packages on https://deb.torproject.org/torproject.org/dists/ again sometime before September 2017 it would be great if you could share them. (the first tor 0.3.1.x alpha version got release on 2017-05-22) background: I would use that information to decide whether to keep or remove alpha support from relayor [1] (which depends on alpha packages from deb.tpo) thanks, nusenu [1] https://github.com/nusenu/ansible-relayor -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 1

Consensus Weight calculation
by Vort 01 Jul '17

01 Jul '17

Hello. Recently I have decided to create a new relay. After several days of waiting, I have realized that decision of Bandwidth Authorities, that my bandwidth is 1000 times lower than it should be, is pretty stable. That is bad on its own, but I was wandering - how many other relays suffers from the same problem? Since all network data is open to analysis, I have decided to calculate some statistics. As "Consensus Weight", theoretically, should correspond to relay's bandwidth, first thought was to compare it with "Advertised Bandwidth" value (assuming there not too many liars on the network). The result has revealed some anomalies: https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8e… First, and most important, - a lot of relays have bandwidth estimate in range 0-50: 1082 of them. Second - there are incorrect estimates for popular bandwidths of 5, 10 and 20 MBits. Next question was: what estimates was actually assigned to that bandwidth spikes? Maybe all zeroes? This led me to another charts: https://s8.hostingkartinok.com/uploads/images/2017/06/8cefb70fce667a1b89c78… https://s8.hostingkartinok.com/uploads/images/2017/06/2e42634ea3f9b71df8a7f… x here is "Advertised Bandwidth", y is "Consensus Weight". I was expected to see something close to x = y line. But result was much worse. First problem (not too important) is a lot of randomness. 5 MiB relay can be easily detected as 1 MiB or 10 MiB. Second one is a thing, which, probably, steals a lot of available network bandwidth: relays with low "Advertised Bandwidth" gets much less traffic than they can handle. Almost no relay with speed < 500 KiB is rated correctly. Similarly, high-speed relays have higher weight than needed. If all 0-50KiB-estimated relays are capable of serving at least 100 KiB, fixing this problem will lead to ~ (100-25)*1082 = 82 MiB/s increase of network bandwidth. But they have even more potential, I think. Do anyone have ideas how to solve this problem? -- Vort

2 17

Tor CPU usage
by Arisbe 30 Jun '17

30 Jun '17

I have a small Tor exit relay (VPS) running at +90% CPU capacity. Memory usage is negligible. I am unable to launch ARM as the single CPU cannot process both Tor and arm. Traffic is mostly high for a small node. I have CPUsNum set at 2 in my torrc from its original setup. However, pidstat 5 -p <pid> shows that only 1 CPU is employed. lscpu shows that the VPS is allotted 2 cpus. CPU speed is around 2.44 M. I'm hoping someone has some experience with this issue and can give me advice.

2 3

Two new exit nodes online
by Tor Node Admin ＠ SechsNullDrei.org 29 Jun '17

29 Jun '17

Good morning, I have brought two new exit nodes online, ephesys0 and ephesys1 . Both are registering on atlas, and both have picked up the exit flag, so I'm providing notice for those who want to take a look at them and provide feedback on their configuration. Make your day great, Isaac, <mailto:Tor@SechsNullDrei.org> Tor(a)SechsNullDrei.org

3 3

2 beginner questions
by Torix 29 Jun '17

29 Jun '17

After running my first relay for a month at a RelayBandwidthRate of 200 KBytes/300KBytes burst, averaging 3-5 GiB per day, I upped it to 300KBytes/400 burst on the 22nd and reloaded the torrc. I don't know why I am now pushing so much more through this simple middle relay. My flags have not changed: Fast, HSDir, Running, Stable, V2Dir, Valid Here is my daily vnstat: 06/21/2017 1.83 GiB | 1.82 GiB | 3.65 GiB | 354.28 kbit/s 06/22/2017 1.98 GiB | 1.98 GiB | 3.96 GiB | 384.34 kbit/s 06/23/2017 1.68 GiB | 1.67 GiB | 3.34 GiB | 324.47 kbit/s 06/24/2017 2.33 GiB | 2.33 GiB | 4.66 GiB | 452.47 kbit/s 06/25/2017 4.00 GiB | 3.98 GiB | 7.98 GiB | 774.93 kbit/s 06/26/2017 6.45 GiB | 6.38 GiB | 12.83 GiB | 1.65 Mbit/s The number of inbound connections has gone up as well, to sometimes 3500 from a normal of 700-800. I am now on track to do about 17 Gib today. I expected to increase to maybe 6 or 7 GiB/day. What perked things up? The reload, or has the new bandwidth rate raised this realy above the average in some way? Really asking because I'm nervous about the ISP noticing, but wonder if it will just increase to the total bandwidth limit 24/7 of 26GiB/day. Hate to run it parttime to a size limit. 2nd question: Why do I have 1903 inbound, but only 132 outbound connections? Shouldn't the extra connections disappear after 10 min or so of inactivity? My flags all seem okay, and Tor would tell me if my relay was misconfigured, methinks, so this is just my not knowing enough, I hope. Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

GeoIP file
by Ian Zimmerman 29 Jun '17

29 Jun '17

How does the tor daemon read the GeoIP database file? Does it read the whole file once when starting up, or every time it needs to resolve an IP, or something in between (say, it builds an index in memory on startup and then seeks to locations in the file when looking up)? I am asking because I want to know if I need to restart, SIGHUP or in some other way kick the daemon after I install a new GeoIP file into place. -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html

3 4

申请
by 龚明福 28 Jun '17

28 Jun '17

2 3

Exit / Bad Gateway
by Sebastian Urbach 27 Jun '17

27 Jun '17

Dear list, My Exit: https://atlas.torproject.org/#details/4198BD138E5E11B15B05C826B427148CED7D9… My Consendus Weight dropped to 20 today and i found the following in notices.log: Jun 27 12:03:35.000 [warn] http status 502 ("Bad Gateway") reason unexpected while uploading descriptor to server '154.35.175.225:80'). Jun 27 12:07:35.000 [warn] Received http status code 502 ("Bad Gateway") from server '154.35.175.225:80' while fetching "/tor/server/d/C8B7BA97808F42802FCC2DF231A85ACB5B8D848A.z". I'll try again soon. Any ideas what to do or just sit it out ? -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

5 5

Tor relay
by Cryptic Admin 27 Jun '17

27 Jun '17

Tor relay

1 0

申请
by 龚明福 26 Jun '17

26 Jun '17

1 0

Re: [tor-relays] I've suddenly started seeing a lot of these in our exit's logs
by tor＠t-3.net 25 Jun '17

25 Jun '17

>> On 23 Jun 2017, at 04:57, tor(a)t-3.net wrote: >> >> >> I've suddenly started seeing a lot of these in our exit's logs: >> >> Rejecting INTRODUCE1 on non-OR or non-edge circuit ...…. > >Did you upgrade the Tor version on your relay recently? >What are the old and new versions? > >(I'm guessing that this was part of the 0.2.9.11 or 0.3.0.8 bugfix, >but it's hard to tell without further info.) > >T > >-- >Tim Wilson-Brown (teor) > >teor2345 at gmail dot com >PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >ricochet:ekmygaiu4rzgsk6n >xmpp: teor at torproject dot org No changes server-side. These just starting popping up out of nowhere. Not saying they are a malfunction and the code isn't doing exactly what it's supposed to - just that it's happening. Our tor version is a bit old compared to the ones you listed. Do you know what the correct repo is that we should be using for Tor for CentOS/RedHat ?

2 1

torservers.net relays still putting tor users at risk
by nusenu 25 Jun '17

25 Jun '17

Moritz wrote (2017-06-10): > Our MyFamily statements are badly out of > sync. Will fix this next week. you are still putting tor users at risk https://nusenu.github.io/OrNetStats/ -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

Performance
by Sebastian Urbach 25 Jun '17

25 Jun '17

Dear list, I noticed a higher CPU load on my Exit since i recently upgraded from 0.2.9.x to 0.3.0.x and thought maybe it is just a matter of tweaking the config for 0.3.0. I could not find anything wrong and checked: https://metrics.torproject.org/torperf.html Is it just me or does that looks like a major Performance Downgrade for the whole Network since 0.3.0.x was introduced ? Looks to me like roughly 50% or more loss of Performance depending on the File size. Was that to be expected for 0.3.0.x ? -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

3 3

I've suddenly started seeing a lot of these in our exit's logs
by tor＠t-3.net 22 Jun '17

22 Jun '17

I've suddenly started seeing a lot of these in our exit's logs: Rejecting INTRODUCE1 on non-OR or non-edge circuit .......

2 1

Exit node restarts itself.
by Alan 22 Jun '17

22 Jun '17

I've started to see my Exit node restart itself. There is a warning in the log pointing to a problem with OpenSSL but I don't know how to proceed. Jun 21 03:07:03.000 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) opening new log file. Jun 21 03:07:03.619 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running with 1000105f: OpenSSL 1.0.1e-fips 11 Feb 2013). Jun 21 03:07:03.647 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1e- ips and Zlib 1.2.7. Jun 21 03:07:03.647 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jun 21 03:07:03.647 [notice] Read configuration file "/usr/share/tor/defaults-torrc". Jun 21 03:07:03.647 [notice] Read configuration file "/etc/tor/torrc". Jun 21 03:07:03.650 [notice] Based on detected system memory, MaxMemInQueues is set to 1464 MB. You can override this by setting MaxMemInQueues by hand. Jun 21 03:07:03.650 [warn] Tor is running as an exit relay. If you did not want this behavior, please set the ExitRelay option to 0. If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility. Jun 21 03:07:03.650 [notice] Opening Socks listener on 127.0.0.1:9050 Jun 21 03:07:03.650 [notice] Opening Control listener on 127.0.0.1:9051 Jun 21 03:07:03.650 [notice] Opening OR listener on 0.0.0.0:8081 Jun 21 03:07:03.651 [notice] Opening Directory listener on 0.0.0.0:8080 Jun 21 03:07:03.000 [notice] Not disabling debugger attaching for unprivileged users. Jun 21 03:07:03.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jun 21 03:07:03.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jun 21 03:07:03.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. Jun 21 03:07:03.000 [warn] Fixing permissions on directory /var/lib/tor Jun 21 03:07:03.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECD H much faster.

4 8

keypair does not match its older value
by Alexander Nasonov 21 Jun '17

21 Jun '17

Hi, I tried moving a tor relay with offline master key to a new host but something went wrong and it printed several warnings: http status 400 ("Looks like your keypair does not match its older value.") response from dirserver What did I screw up and how to fix this problem if it happends again? I suspect it will happen again because I generate a new signing key more frequently than necessary. I create '15 days' key every week and upload it (over onion ssh connection). This scheme should be resistant to occasional upload failures but it's not clear which of the last three signing keys to use on restart. If passing the wrong key can bring down the relay I need to switch to a different scheme. I'm thinking about adding these commands to my crontab: $ crontab -l @weekly scp "${DESTDIR}/keys/ed25519_signing_cert" "${DESTDIR}/keys//ed25519_signing_secret_key" ${ONION:?}: @monthly tor --hush --keygen --SigningKeyLifetime '1 month' "${DESTDIR:?}" && {{{scp command from the previous line}}} Are there any potential problems with this approach (e.g. 28 days in Feb vs 31 days in March)? -- Alex

4 5

artikel5ev.de: tor relays and the danger of end to end correlation
by nusenu 21 Jun '17

21 Jun '17

Hi, thanks for running relays! would you mind fixing the MyFamily in your torrc files? https://nusenu.github.io/OrNetStats/ https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#see-httpsww… dc6jgk15TEST has been around since 2017-04-27 (more than a few hours or days of 'test') thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

Re: [tor-relays] Consensus Weight calculation
by Vort 21 Jun '17

21 Jun '17

>> Are there any news regarding that problem? > It's a complicated problem. > We need to work out why it is happening before we can fix it. I am not sure if I really can help with BwAuth's algorithms. But that's what I would do in such situation: First, most important thing, is a clear goal. As BwAuth's task is to make a measurements, then theirs result must be clearly defined. So, the question is - how an ideal "w" ([Consensus] Weight) looks like? Suppose we have some perfectly measured parameters for relay: perfect_measured_bandwidth (KiB/sec) and perfect_measured_latency (sec). Their exact definition can be omitted now for simplicity. Then ideal_w should be equal to: ideal_w = perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth / perfect_measured_latency or, maybe, something else? Once this question is clear, then it is possible to see how existent implementation is far from this ideal. And here is part two: why it is different? It is some noise that can't be eliminated? Or algorithm for some reason converges to incorrect values? BwAuths have some debug information. This can help to investigate problem. There are also the possibility of doing manual checks. Which then can be compared to debug logs of BwAuth. Maybe my approach is not so good and you will choose another. But, anyway, thanks for working on this problem. -- Vort

1 0

Exit notice in Spanish
by ilv＠torproject.org 20 Jun '17

20 Jun '17

Hola, I wanted to let you know that at derechos digitales we wrote a basic tor exit notice in spanish. You can find it in [1] and a mirror in [2]. We look forward to receive feedback from the community to improve it (content, ui, etc), hoping that it could be useful to other relay operators. We have also added legal info of some countries. Feedback and contributions in this matter are welcome as well :) p.s.: someone on global-south list also told me about [3]. [1] https://0xacab.org/tortola/exit-notice [2] https://github.com/derechosdigitales/tor-exit-notice [3] https://github.com/chgans/tor-exit-notice Saludos. -i

1 0

I would lime to poste on this list
by Andree-anne Tremblay 20 Jun '17

20 Jun '17

Tank you

1 0

sharing tor relay at night or working hours ? make sense ?
by Zalezny Niezalezny 20 Jun '17

20 Jun '17

Hi, I have 100mbit Up/Down connection at home. Most of the day, my connection is not use. Mostly between 22:00-17:00. I would like to share my Internet connection for Tor. If I will setup some crontabs to start/stop my tor relay between that hours, will it work ? Does it make sense ? Will TOR network know that my relay is working only between 22:00 and 17:00 and will push some more traffic to me ? How to properly configure such a relay which is working only for a few hours per day ? Cheers Zalezny <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

7 8

libzstd and/or liblzma
by Felix 15 Jun '17

15 Jun '17

Hi nusenu thanks again for your responses ! > the context of that line is longer in the original changelog: > https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=tor-0.3.1.2-alpha#n… That's where I got it from >> Might ports archivers/zstd only do the job (OR-type): >> >> Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on >> FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3, >> Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0 > > see the related comment by the FreeBSD port maintainer: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219571#c2 Good hint. When I follow the link I find the archivers/zstd port will be included which seems up to date (libzstd.so.1.2.0, 30 Jul 2016). That's what I did. Fine. Which is the right port for lzma ? When I try to include archivers/lzmalib (liblzma.so.1.1.0, 23 Sep 2008) I find it un-maintained, old and Tor does not configure for it: checking for LZMA... no configure: WARNING: Unable to find liblzma. checking for ZSTD... yes Is there a better lzma port ? -- Cheers, Felix

2 1