- tor-relays - lists.torproject.org

Short Research Survey
by Anon-research 12 Sep '19

12 Sep '19

Dear Tor relay operators, We are a team of researchers at MIT, and we would like to ask Tor relay operators to participate in a short and anonymous survey (no personal information or IP address collected). This study is focused on the importance of providing anonymity by volunteers in various contexts, and will take no more than 5-10 minutes to finish. You can learn more and take the survey at this link: https://mit.co1.qualtrics.com/jfe/form/SV_6W3YXSCnqMVGPs1 Your input is very valuable to our study, and we look forward to your feedback. Please feel free to email us at anon-research(a)mit.edu if you have any questions. (Our survey platform unfortunately uses JavaScript. We apologize for being unable to switch it off. We would be grateful for your participation if you are comfortable taking the survey.)

3 2

Re: [tor-relays] Running on a Raspberry Pi
by nottryingtobelame＠protonmail.com 10 Sep '19

10 Sep '19

My primary relay runs on a Pi 3B. 903CA67D0DEB74CFBB01432840A26CB8C6C18FDF. According to the logs, it's sending and receiving a total of about 130 GB per day. A Pi 4 should definitely be able to handle it. Pi Zeroes had a conflict with the name of the CPU architecture and so Tor apparently never worked quite right on them. I'm not an expert, but my guess is that the relay just had to reset its advertised bandwidth and has to build back up again. Hope this helps.

1 0

FW: Lots of spam on new tor exit node.
by email-group＠tor.bband.net 10 Sep '19

10 Sep '19

I have recently setup a new tor exit node but since about an hour of setting it up it has been almost maxed out with spam. https://metrics.torproject.org/rs.html#details/4AFECB973C2268D5074D8DEDAF0BD B604C89ED50 How can I combat it? I turned the node off for about an hour from about 6.30am GMT but the user reconnected. From the looks of it they are connecting through the tor network. DNS logs are looking like it is targeting illicit Russian drug forums almost all with .biz domains.

3 3

What could cause a huge clock skew (9 days) across Tor restarts - anyone else experienced something like this?
by s7r 08 Sep '19

08 Sep '19

Hello, I'd like to hear if anyone else experienced this and has an idea of what the cause might be. I did not oped a ticket about this yet because I am not sure there is a problem in Tor, and it eventually healed by itself. The relay was running just fine. Server had an accurate time before upgrade and time service ntp was running. I only did an upgrade to Tor from the latest nightly build and of course it does a service stop -> upgrade -> service start. After Debian finished installing the new Tor, I did as usual: check the log file to see that all is OK and circuits were built and descriptors published, etc. I saw this: The log before restart was reporting: Sep 06 21:03:16.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 06 21:03:17.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Sep 06 21:03:46.000 [notice] Clean shutdown finished. Exiting. [skipped boring part intentionally] Aug 28 07:40:07.000 [warn] Our clock is 9 days, 11 hours, 20 minutes behind the time published in the consensus network status document (2019-09-06 23:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Aug 28 07:40:07.000 [warn] Received ns flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 9 days, 11 hours, 20 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Aug 28 07:40:07.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -818406 in ns flavor consensus from CONSENSUS; CLOCK_SKEW; count 2; recommendation warn; host ? at ?) Aug 28 07:40:08.000 [warn] Our clock is 9 days, 12 hours, 20 minutes behind the time published in the consensus network status document (2019-09-07 00:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! Aug 28 07:40:08.000 [warn] Received microdesc flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 9 days, 12 hours, 20 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Aug 28 07:40:08.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Clock skew -822006 in microdesc flavor consensus from CONSENSUS; CLOCK_SKEW; count 3; recommendation warn; host ? at ?) and then Sep 06 21:04:50.000 [notice] Starting with guard context "default" ...proceed to normal start and everything as usual from now... So, Tor had the time Sep 06 21:03:46.000 before restart. After restart, it thought it had Aug 28 07:40:07.000 and then Aug 28 07:40:08.000 and then it healed and reported Sep 06 21:04:50.000. This is kind of odd. What could be the reason for this? The server is just a Debian machine that runs Tor and nothing else. Thanks!

3 4

Re: [tor-relays] Operator straw poll: Reasons why you use Tor LTS versions?
by starlight.2018q2＠binnacle.cx 07 Sep '19

07 Sep '19

My relays track current stable, though I prefer going slow updating unless a major CVE/TROVE lands. LTS is beneficial for many reasons and, from the enthused developer perspective perhaps best viewed as "necessary evil." Rather than thinking about killing LTS, is better to think about ways to campaign for and facilitate rapid migration to a latest LTS release when very important features arrive. Possibly this translates to early retirement via blacklisting of the eldest version.

1 0

Tor exit relay in Finland still being attacked
by potlatch 05 Sep '19

05 Sep '19

I had TorExitFin [0] down for a few days hoping the non-Tor Iranian intruders would wander off. I restarted it today and before NYX could come up there were 257 Iranian IPs present (nicely automated!). The IP addresses range over all of the IP addresses allotted to Iran so their usage must come from a high authority to get that kind of access. NYX communications page showed that none of these had hashed fingerprints. At the same time 3 IPs came up from other countries with fingerprints. Should I leave this shut down for the security of the network? -potlatch [0] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Low-bandwidth relay
by John Williams 04 Sep '19

04 Sep '19

I've been running tor on my openwrt-based home router (along the lines of 'anonabox'), and I configured it as a non-exit relay, because I thought why not - every little helps, right? I set a very low bandwidth limit, but it was using most of the configured bandwidth, so I figured it was helping. A few days ago I got an email saying my tor version was EOL, so I upgraded from version 0.3.2.10 to 0.4.1.5 (which required upgrading openwrt). Now tor is still working fine for me, but I don't see any network traffic when I'm not using it, so it is evidently not routing any third-party traffic any more. I don't see any errors in the log. Is this (a) expected behaviour because the previous traffic was just a bug in the old version of tor, or (b) an indication that there is something wrong with my upgraded installation? Any suggestions about where I should look would be welcome. I'm considering reconfiguring my system to be a bridge instead of a router, but I would prefer to sort out any possible problems with what I've got now, before making further changes.

2 1

end-of-life relays will be removed from the network eventually
by nusenu 03 Sep '19

03 Sep '19

Patches [1] are being prepared to remove Tor relays running end-of-life versions of Tor eventually. Affected relays as of 2019-09-03 16:00 UTC #relays 1276 CW Fraction 13.25 % Guard 16.91 % Exit 2.19 % Want to know if your relay is affected? Here is a list of affected relays (updated daily): https://nusenu.github.io/OrNetStats/eolrelays The Tor Relay Guide has instructions to help you stay on maintained Tor releases. https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… [1] https://trac.torproject.org/projects/tor/ticket/31549 Tor people are sending out emails (cc'ing network-health): https://lists.torproject.org/cgi-bin/mailman/listinfo/network-health -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 1

Re: [tor-relays] Status of "new" defect #30767 Custom obfs4 bridge does not work on Tor Browser for Android
by nottryingtobelame＠protonmail.com 02 Sep '19

02 Sep '19

Ah, thank you for the reply. Well, I will continue to donate to and support the tor project whenever I can.

1 0

Status of "new" defect #30767 Custom obfs4 bridge does not work on Tor Browser for Android
by nottryingtobelame＠protonmail.com 02 Sep '19

02 Sep '19

I hate to be that guy, but I was wondering if there is any progress on resolving this defect? I'm sure it's not a front burner type of problem, but it would be nice to be able to use the Android app as intended. Using Orbot/Orfox as a backup feels like a poor workaround when there's an official Tor browser app. If I'm being impatient, just let me know - I'm not familiar with what's normal during this process. Thanks in advance.

3 2