- tor-relays - lists.torproject.org

IPv6 to IPv4 tor exit relays would fix many daily tor-problems
by Fof582 05 Jul '17

05 Jul '17

I have access to a fast internet connection. This connection only have ipv6 IP and i can access the IPv4 network over the ISPs 6to4 bridge. So there are already many users using one single IPv4 address at this ISP. Sadly its technical as far as i understood at the moment not possible to run a IPv6-only exit node. If i could run such, the people on the world that could access IPv6-adresses also would be able to connect to my IPv6 exit node. Then they can finally access over IPv4 all the webpages that normally block tor users, bother them with captchas, ... Such tor-users could also finally access freenode irc again. I would like to give such service-blocked tor users again access to all websites of the internet by providing such a 6to4-tor exit node. Is there any progress at this?

5 10

What is the right repo for Redhat/CentOS Tor?
by tor＠t-3.net 04 Jul '17

04 Jul '17

The files in the repo location we have configured have not changed recently, and I know that Tor's been updated. The repo we're configured for is based out of: https://deb.torproject.org/torproject.org/rpm/el/6/x86_64

2 1

Exit flag and port 6667 vs 6697
by Igor Mitrofanov 04 Jul '17

04 Jul '17

Hi, I am trying to run a few Exit relays on my 1 gbps connection. To keep donating the exit capacity to the Tor project I have to keep abuse reports to a minimum. In order to have the Exit flag I have read that I have to keep two of ports 80, 443 and 6667 open, plus allow exiting to at least one /8 network - is that still the Dir spec? Is it correct that without the Exit flag, no clients will choose the relay for their circuits - even if its Exit policy allows the port they need? For example, take a look at the "cry" relay (one of top 10) - it is not marked as "Exit" as it only allows ports 6660-6667 - does that mean it is only ever used as a middle relay? I have read that port 80 generates quite a bit of abuse complaints as it is used to tunnel non-HTTP traffic, by malware, etc. So, choosing ports 443 and 6667 to get the 'Exit' flag looks like the safest choice. I have also read that ports above 1024 are more likely to used by BitTorrent clients, so they are to be rejected in order to minimize abuse. My current, rather paranoid, list of accepted ports looks like this: 20-21, 53, 443, 993, 995, 6667. I am not sure how useful this is to Tor, and whether I will actually avoid complaints, but I guess I can only wait and see. My question is about 6667 - should Tor's 'Exit flag policy' allow 6697 (IRC encrypted over SSL) as an alternative to 6667? I would rather support people using 6697, if I had the choice. Thanks, Igor

3 3

Multiple relay instances, debian + systemd
by Paw Møller 03 Jul '17

03 Jul '17

Dear all, I run an exit node on debian strech, fingerprint 13E75F70220903A68BAF1F80B3DA9AB913961841 I would like to use more bandwidth, but I'm unsure how to do that with systemd. So, Lets say I want two exit nodes, each at 20MB/s. As per https://www.torservers.net/wiki/setup/server#high_bandwidth_tweaks_100_mbps, I am supposed to use tor-instance-create tor{1,2} [1] systemctl enable tor@tor1 etc. but what goes in the individual tor@tor1 torrc in /etc/tor/instances/tor1/torrc and what goes in the main instance in /etc/tor/torrc? Looking at the status for the new instance systemctl status tor@tor1 Process: 22722 ExecStartPre=/usr/bin/tor --defaults-torrc /var/run/tor-instances/tor1.defaults -f /etc/tor/instances/tor1/torrc --verify-config it seems the main torrc is not read, so maybe this is just an fancy way of doing the "old" /usr/sbin/tor -f /usr/local/etc/torrc1 /usr/sbin/tor -f /usr/local/etc/torrc2 ... with separate configurationfiles and datadir? I have a few extra ipv4 addresses. Should I allow each instance it's own IP or is sharing fine with one having (80,443) and the other (9091,9030) as (QR,DIR)port? I am aware that one IP can only be shared between two instances. Another question: Should I set the NumCPUs option to 2 or just leave it at 0(default)? https://www.torproject.org/docs/tor-manual.html.en#NumCPUs The processor is a bit old: Model name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz pidstat 5 -p `pidof tor` Linux 4.9.0-3-amd64 (tiger) 2017-07-01 _x86_64_ (4 CPU) 23:38:33 UID PID %usr %system %guest %CPU CPU Command 23:38:38 127 10706 38,60 16,80 0,00 55,40 2 tor 23:38:43 127 10706 37,20 14,20 0,00 51,40 3 tor 23:38:48 127 10706 33,20 12,20 0,00 45,40 3 tor 23:38:53 127 10706 41,00 11,80 0,00 52,80 3 tor 23:38:58 127 10706 46,40 14,80 0,00 61,20 2 tor And finally: Do you change the number of maximum file descriptors? As of now, cat /proc/sys/fs/file-nr 9248 0 163085 where ls -l /proc/`echo $(pidof tor)`/fd | wc -l 5866 Best, Paw [1] http://manpages.ubuntu.com/manpages/zesty/man8/tor-instance-create.8.html

4 3

[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