- tor-relays - lists.torproject.org

Relays operators meetup
by Nicolas Braud-Santoni 26 Dec '17

26 Dec '17

Hi ! (Sorry for the late announcement, I somehow forgot to fire off the email...) The Tor relays operators meetup, at 34C4, will be TOMORROW (day 1), from 18.30 to 20.10, in lecture room 11 (in CCL, 2nd floor) : https://events.ccc.de/congress/2017/wiki/index.php/Session:Tor_relays_opera… Best, nicoo

1 1

Decline in relays
by David Goulet 26 Dec '17

26 Dec '17

Hello everyone! Since July 2017, there has been a steady decline in relays from ~7k to now ~6.5k. This is a bit unusual that is we don't see often such a steady behavior of relays going offline (at least that I can remember...). It could certainly be something normal here. However, we shouldn't rule out a bug in tor as well. The steadyness of the decline makes me a bit more worried than usual. You can see the decline has started around July 2017: https://metrics.torproject.org/networksize.html?start=2017-06-01&end=2017-1… What happened around July in terms of tor release: 2017-06-08 09:35:17 -0400 802d30d9b7 (tag: tor-0.3.0.8) 2017-06-08 09:47:44 -0400 e14006a545 (tag: tor-0.2.5.14) 2017-06-08 09:47:58 -0400 aa89500225 (tag: tor-0.2.9.11) 2017-06-08 09:55:28 -0400 f833164576 (tag: tor-0.2.4.29) 2017-06-08 09:55:58 -0400 21a9e5371d (tag: tor-0.2.6.12) 2017-06-08 09:56:15 -0400 3db01d3b56 (tag: tor-0.2.7.8) 2017-06-08 09:58:36 -0400 64ac28ef5d (tag: tor-0.2.8.14) 2017-06-08 10:15:41 -0400 dc47d936d4 (tag: tor-0.3.1.3-alpha) ... 2017-06-29 16:56:13 -0400 fab91a290d (tag: tor-0.3.1.4-alpha) 2017-06-29 17:03:23 -0400 22b3bf094e (tag: tor-0.3.0.9) ... 2017-08-01 11:33:36 -0400 83389502ee (tag: tor-0.3.1.5-alpha) 2017-08-02 11:50:57 -0400 c33db290a9 (tag: tor-0.3.0.10) Note that on August 1st 2017, 0.2.4, 0.2.6 and 0.2.7 went end of life. That being said, I don't have an easy way to list which relays went offline during the decline (since July basically) to see if a common pattern emerges. So few things. First, if anyone on this list noticed that their relay went off the consensus while still having tor running, it is a good time to inform this thread :). Second, anyone could have an idea of what possibly is going on that is have one or more theories. Even better, if you have some tooling to try to list which relays went offline, that would be _awesome_. Third, knowing what was the state of packaging in Debian/Redhat/Ubuntu/... around July could be useful. What if a package in distro X is broken and the update have been killing the relays? Or something like that... Last, looking at the dirauth would be a good idea. Basically, when did the majority switched to 030 and then 031. Starting in July, what was the state of the dirauth version? Any help is very welcome! Again, this decline could be from natural cause but for now I just don't want to rule out an issue in tor or packaging. Cheers! David -- HiTVizeJUSe9JPvs6jBv/6i8YFvEYY/NZmNhD2UixVY=

9 13

bridges
by Mr Xxx 26 Dec '17

26 Dec '17

2 1

Relay Search bandwidth graph update issue
by Ralph Seichter 26 Dec '17

26 Dec '17

Relay Search shows odd detail information for three of my nodes. The history graphs for bytes read/written per second shows no data beyond 2017-12-13 (one node) or 2017-12-17 (two nodes), respectively. The probability and consensus weight graphs appear correct. Other nodes of mine are shown with up-to-date information for all graph types. Is anybody else experiencing this as well? -Ralph

3 6

34c3
by Felix 26 Dec '17

26 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everybody Is there an assembly or room for a concourse of Tor people? Some coordinates like room number and utc would be apprechiated. Hope to see you folks there :) - -- Cheers, Felix -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJaQgVjAAoJEF1W24InZUQdSRgP/2g7ly+UhLA78YZqgGntOXbw jJZ4NPQSUHBggb+FHNUZeADajCVqfaLlSUpgkfl83OyciQuCWnirC8F0sO5pttp0 zJI9agcbaDza2d3uEQEg9ZqVR6doPlAHpnNlCtRmI+sOmvCIL6jna/XHVyIjxrb/ WcvJyK29GPLPzm/eGecs1dv+WtObTpOHtcI/UxXVUJBFQsrzrw6/kKfxvJmGVY/I GHg6IJQkKulVXxhfK+xoX0VLX+W3FD5lnsKfqAgD9ngTL/CB6jv+tbgtWvm4sIUh OaLcCYK4xOicyWj/FMyIHhAwo0Ges8uue++rFmJ5KXv1wn/+eUp6XvLdccpNKzVe KR/TuEdf+HFxLdbIMas9tsNjUpo3kqQSjqXSr67qbth7Bya8RQUp19RLZyIjc5Yy Ou5lmHt5tKd9iq9Jj8xwQbpu0ZvgUzX54Y53xXDVPpcd1NEE5LsaCi9cuhX65xBg MyFV7GuIWYL2BjpvQkLb10dSfKfpqW63F3cjR6aFSSieaBmEug62lNVk43N8W7Hi OxpNhex7gKb9oGxM5CEbYib2Cp3fUsDY7Fbp0ggIK2YglpTPm5QHqcLanlcJiinB OIdndAYTl+nHEr9hm4EDI9KmkFUqgzAKpBpm8h2Ku0pMSWEB+VRQY2eaGTBpDd15 vjZ+WwKjplS6mQZ/oLiq =L7/F -----END PGP SIGNATURE-----

2 1

Can it be done? - IPv6 only Relay
by Stijn Jonker 25 Dec '17

25 Dec '17

Hi tor geniuses, Having some bandwidth to spare, and "some" IPv6 addresses but no IPv4. I decided to setup an IPv6 only relay, and for diversity on OpenBSD, but I'm having trouble getting online. Is there any feasible way to do this as IPv6 only relay? [root@tornode2 tor]# grep -v -e ^$ -e ^# /etc/tor/torrc SOCKSPort 0 # Default: Bind to localhost:9050 for local connections. Log notice syslog RunAsDaemon 1 DataDirectory /var/tor ORPort 443 Address tornode2.sjc.nl OutboundBindAddress [2001:x:x::x] Nickname <<SNIP>> DirPort 80 DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily <<REMOVED>> User _tor ExitPolicy reject *:* # no exits allowed ExitPolicy reject6 *:* # no exits allowed AuthDirHasIPv6Connectivity 1 ClientUseIPv6 1 ClientPreferIPv6ORPort 1 ClientPreferIPv6DirPort 1 Thx, Stijn

4 8

Fwd: Re: Become a Fallback Directory Mirror
by Arisbe 23 Dec '17

23 Dec '17

1 0

getrelays
by G Dived 23 Dec '17

23 Dec '17

Neet relays 发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用

2 1

MaxMemInQueues - per host, or per instance?
by Igor Mitrofanov 23 Dec '17

23 Dec '17

Hi, Is MaxMemInQueues parameter per-host (global) or per-instance? Say, there are 10 relays on the same 24 GB host. Should I set MaxMemInQueues to 20 GB, or 2 GB in each torrc? Thanks, Igor

4 6

New Relay Online/Working on AWS Cloud Torproject
by Conrad Rockenhaus 22 Dec '17

22 Dec '17

Howdy, Early this morning (3 AM CST) I brought a non-exit relay named “ConradsAWSRelay” online. I would appreciate it if someone would take an objective look at it to see if the relay is fast enough and bringing useful services to the tor network. Additionally, I know that people have been working on ansible solutions regarding the installation of tor and what not, but that being said, I’m working on an AWS specific solution to replace the previous Cloud torproject that we had years ago. I will keep everyone in the loop, but I think its time that we have a cloud specific solution for rolling out tor. Thanks, Conrad Rockenhaus

4 10

warning messages
by Arisbe 22 Dec '17

22 Dec '17

Hello All, In recent weeks I have noticed some warning messages on several of my VPS relays [1], [2]. "20:48:48.000 [warn] Tried to establish rendezvous on non-ORcircuit with purpose Acting as rendevous (pending)" I get these in modest numbers as (97 hidden). Is this a characteristic of the guard relay abuse issue? Thanks for some advice. [1] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 [2] B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1

2 1

first impression with 0.3.2.8-rcant a fast exit relay
by Toralf Förster 22 Dec '17

22 Dec '17

With 0.3.2.7-rc the command /usr/sbin/iftop -B -i eth0 -P -N -n -m 320M showed every then and when (few times in a hour) for 10-20 sec a traffic value of nearly 0 bytes for the short-term period (the left of the 3 values). Usuaally I do poberve between 6 and 26 MByte/sec. With the Tor version from today now the outage is about 1-2 sec, but does still occur. Not sure, if this is an expected behaviour or a local problem. -- Toralf PGP C4EACDDE 0076E94E

4 4

Re: [tor-relays] Become a Fallback Directory Mirror
by Dennis Emory Hannon 22 Dec '17

22 Dec '17

Tim, 5E56738E7F97AA81DEEF59AF28494293DFBFCCDF Thanks, Hostmaster@: Mr. Dennis Emory Hannon BackplaneDNS.org / Backplane LLC Phone: +1 (716) 348-0064 Linkedin: http://linkedin.com/in/dennis-hannon-52236019/

1 0

IPv6 Issue with Relay
by Conrad Rockenhaus 22 Dec '17

22 Dec '17

Hello, One of the relays that I brought online yesterday, ConradsAWSExit (Hash 1B47E33F9D422CC97BD2DDA1F082BFF2FC58E79A) is showing up on Atlas that the IPv6 OR is unreachable. The other relay is working just fine with IPv6. I’ve confirmed that the following entries are in torrc: ORPort 9001 ORPort [2600:1f14:ede:d601:e107:1a4b:ba3:803]:9001 IPv6Exit 1 Just to confirm, here’s the output from ifconfig, that is the IP: inet6 2600:1f14:ede:d601:e107:1a4b:ba3:803 prefixlen 64 scopeid 0x0<global> I have confirmed that all of the applicable Security Group rules are configured correctly: Custom TCP Rule TCP 9001 0.0.0.0/0 ORPort Custom TCP Rule TCP 9001 ::/0 ORPort Custom TCP Rule TCP 9030 0.0.0.0/0 DIRPort Custom TCP Rule TCP 9030 ::/0 DIRPort Plus, I have confirmed with a telnet -6 to port 9001 from both my house and my servers at OVH in Canada that I’m able to connect to port 9001 via the IPv6 address on this node. So, my question is…what could I be missing here that is causing atlas to say that IPv6 is unreachable? I’ve been looking into this through the day and would like to kind of close it out, got a bunch of emails to catch up on hehe :D, so any input would be appreciated. Thanks, Conrad

3 5

Ongoing DDoS on the Network - Status
by David Goulet 21 Dec '17

21 Dec '17

Hi everyone! I'm David and I'm part of the core development team in Tor. A few minutes ago I just sent this to the tor-project@ mailing list about the DDoS the network is currently under: https://lists.torproject.org/pipermail/tor-project/2017-December/001604.html There is not much more to say about this right now but I wanted to thanks everyone here for running a relay, this situation is not pleasant for anyone especially for relay operators for which you need to deal with this attack (and extra bonus point during the holidays for some...). Second, everyone who provided information, took the time to dig in this problem and sent their findings on this list was a HUGE help to us so again, thank you very much for this. We will update everyone as soon as possible on the status of the tor releases that hopefully will contain fixes that should help mitigate this DDoS. Cheers! David -- aFJe0kbRB1zZXgwFQIvBG0Skn3xAsDGxVQsAiguKjY8=

2 3

restarting tor service after AccountingMax has been reached
by Fabian A. Santiago 21 Dec '17

21 Dec '17

I'm noticing that if i attempt to restart tor AFTER AccountingMax has been reached (meaning it's currently hibernating), tor itself fails to start. if i increase AccountingMax in torrc, then it restarts just fine. normal? -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

3 8

Guard node suddenly sending twice what it receives
by Logforme 20 Dec '17

20 Dec '17

My little guard node (855BC2DABE24C861CD887DB9B2E950424B49FC34) have suddenly started to behave strangely. iftop (my "bandwidth monitor"), shows twice as much sent traffic as received traffic. The traffic seems to be distributed to a lot of ip addresses. No ip address stands out as receiving very much traffic: https://imgur.com/a/dAUzc Given the last few days of DDoS attacks (my node is still targeted by those) I naturally assume this is another attack. First it is lots of connections (mitigated with connection limits) Then it is massive amounts of memory per circuit (MaxMemInQueues fixes that) And now this. Could this be a third attack vector or am I seeing something "normal" (though I often check my bandwidth and I've never seen this before). My node recently got the HSDir flag after the last crash. Could the network be starved for HSDir machines and this is what I'm seeing? Being a linux noob I don't know how to figure out exactly what kind of traffic this is. Suggestions gratefully accepted.

2 3

botnet? abusing/attacking guard nodes
by starlight.2017q4＠binnacle.cx 20 Dec '17

20 Dec '17

Guard relay here appears to have come under steadily increasing abuse over the last several months. Belive the two previous threads relate to the same issue: Failing because we have 4063 connections already // Number of file descriptors DoS attacks are real Several times a day a large burst of circuit extends are attempted resulting in log flooding with [Warning] assign_to_cpuworker failed. Ignoring. where the above indicates a circuit-launch failed due to a full circuit request queue. Presently the guard runs on an old system lacking AES-NI, and the operation is expansive rather than trivial. Originally thought the events were very brief, but after reducing MaxClientCircuitsPending from a larger value to the default it appears they last between five and ten minutes. The abuser also contrives to create huge circuit queues, which resulted in an OOM kill of the daemon a couple of days back. Lowered MaxMemInQueues to 1G, set vm.overcommit_memory=2 with vm.overcommit_ratio=X (X such that /proc/meminfo:CommitLimit is comfortably less than physical memory) and now instead of a dameon take-out see [Warning] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Removed 1060505952 bytes by killing 1 circuits; 19k circuits remain alive. Also killed 0 non- linked directory connections. As you can see the one circuit was consuming all of MaxMemInQueues. And today this showed up in the middle of a "assign_to_cpuworker failed" blast: [Warning] Failing because we have Y connections already. . . Digging into the source, the message indicates ENOMEM/ENOBUFS was returned from an attempt to create a socket. Socket max on the system is much higher than Y so kernel memory exhaustion is the cause. Implication is a burst of client connections associated with the events, but haven't verified that. An old server was dusted off after a hardware fail and the machine is a bit underpowered, but certainly up to the load that corresponds with the connection speed and assigned consensus weight. AFAICT normal Tor clients experience acceptable performance. The less-than-blazing current hardware illuminates the abuse/attack incidents and inspired the writing of this post.

11 16

Image asset in Tor readme html
by Fabian A. Santiago 20 Dec '17

20 Dec '17

Can the Tor service not serve up a locally referenced PNG file in the readme HTML file used for dirportfrontpage? Mine keeps showing as a broken link. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

3 3

[OrNetRadar] Contact: "dalesolutions2016 at yahoo dot com" (6)
by nusenu 19 Dec '17

19 Dec '17

Hello dalesolutions2016, thank you for adding tor relays to the network! To ensure tor users do not use your relays in multiple positions in a tor circuit (which is not safe), please set the "MyFamily" value in your torrc files. You can find out more about that configuration here: https://www.torproject.org/docs/tor-manual.html.en#MyFamily kind regards, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_ ornetradar(a)riseup.net: > 2017-12-18 > > | Up | Ext | JoinTime | IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamMembers | > |------+-------+------------+----------------+---------------------------------+------+-------+--------+-------+-----------+---------------+---------------| > | 1 | 1 | 10:01:27 | 93.188.164.86 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | Quahog | 1 | > | 0 | 0 | 10:54:31 | 93.188.161.36 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | 1stAmmendment | 1 | > | 1 | 0 | 12:14:36 | 93.188.161.36 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | 1stAmmendment | 1 | > | 1 | 0 | 12:15:57 | 93.188.161.109 | Hostinger International Limited | us | 9001 | 0 | Linux | 0.2.5.16 | MisterPink | 1 | > | 1 | 0 | 12:18:32 | 153.92.209.187 | Hostinger International Limited | gb | 9001 | 0 | Linux | 0.2.5.16 | NCC1701D | 1 | > | 1 | 0 | 12:20:15 | 156.67.220.154 | Hostinger International Limited | cy | 9001 | 0 | Linux | 0.2.5.16 | Montauk | 1 | > > https://nusenu.github.io/OrNetRadar/2017/12/18/a3 > > > > --- > To unsubscribe: <mailto:ornetradar-unsubscribe@lists.riseup.net> > List help: <https://riseup.net/lists> >

1 0

DoS attacks are real
by tordoswitchhunter＠airmail.cc 19 Dec '17

19 Dec '17

This message might be a bit controversial as I am disclosing bunch of client IPs, but you should check incoming ORPort connections on your relay, compare those IPs with usual clients and judge for yourself. I do not believe those are real Tor clients. Those IPs have been collected today from my guard node. Most of them are from LeaseWeb and OVH. :torrelayfilter - [0:0] -A INPUT -p tcp -m tcp --dport 9001 -m connlimit --connlimit-above 4 --connlimit-mask 32 --connlimit-saddr -j torrelayfilter -A torrelayfilter -s 198.7.59.194/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 199.115.112.79/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 207.244.70.120/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.178/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.191/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 207.244.110.200/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.177/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.179/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 85.10.193.240/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 162.210.192.70/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.188/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.180/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.185/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.187/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.190/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.104/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.106/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 149.202.66.206/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.186/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.184/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.192/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.193/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.103/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.107/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 54.36.51.189/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 51.15.161.135/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.6/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.83.3.154/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.72.231/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.237/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 51.15.162.120/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.77.152/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.7/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 95.211.95.10/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 95.211.95.18/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.236/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 95.211.95.14/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.72.66/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 5.79.77.151/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.8/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.87/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.106.246/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.90/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.235/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.89/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.5/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.104.231/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.106.245/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.10/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.86.88/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 213.227.137.9/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 212.32.226.234/32 -p tcp -j REJECT --reject-with tcp-reset -A torrelayfilter -s 37.48.105.240/32 -p tcp -j REJECT --reject-with tcp-reset

2 1

git branch to run from?
by Andreas Krey 19 Dec '17

19 Dec '17

Hi everybody, what is the proper git branch to build and run a relay from? So far I was on release-0.2.9 and just switched to release-0.3.2, but it seems that on either what I pick up there isn't actually a recommended version. - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds(a)*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800

2 1

How long to delist from atlas?
by Fabian A. Santiago 18 Dec '17

18 Dec '17

Hello, I stood up a second Tor relay on an isp who's tos I didn't read carefully and they booted me. That's fine, my mistake. I had a vps and they only allow Tor on dedicated hosts. So I stood it up again on another known good vps provider and gave it the same Nick as the prior attempt. Now both are listed in atlas, same Nick, but one being offline. Is this ok and how long until the offline one is removed from the atlas listing? Thanks. -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

2 2

#34C3 Tor Assembly
by Artikel 5 e.V. 18 Dec '17

18 Dec '17

Hello, when I looked around in the wiki for this years Chaos Communication Congress in Leipzig (Germany) I found that there is not much happening around Tor. So I took the liberty to register a small assembly [1] for Tor involved people to meet, discuss, hack or just sit and relax. This assembly will be in the Hall for "Rights & Freedoms" [2], I am not yet sure where this Hall is, but you'll find it. ;-) If all works fine I should have a DECT phone during the congress (6677), you can also reach my on various channels, one being Twitter [4], I am on the board of Artikel 5 e.V. [3] a non profit running some small relays (and exits) and looking to run more exits. (Looking for hosters preferably in Germany / EU ;-) The idea was more or less "there is no Tor assembly, but I would like to have one", the solution was to register one. I will take care of the basic stuff that has to be organized, would be very happy to get support from anyone and also looking forward to any ideas and questions. This assembly is open to anyone who is interested in Tor or actively supporting it, it is not meant to be a "Artikel 5 e.V." assembly, I just used the organization to register the assembly [5]. Things that we need: - Some Tor related decoration, so if you have anything that we can use there just bring it along and set it up in our space. - If anyone wants to hand out Tor related information/sticker/flyer please feel free to do so, but check what is accepted at the congress. I hope to see some of you guys at the #34C3 in Leipzig. Regards utzer [1] https://events.ccc.de/congress/2017/wiki/index.php/Static:Assemblies [2] https://events.ccc.de/congress/2017/wiki/index.php/Cluster:Rights_%26_Freed… [3] https://www.artikel5ev.de/ [4] https://twitter.com/utzer (holds a bit more information) [5] https://events.ccc.de/congress/2017/wiki/index.php/Assembly:Tor

8 11

Failing: 4063 Connection error
by Kurt Besig 17 Dec '17

17 Dec '17

Where can I set the connection limit higher or is this a result of max bandwidth allowed? This relay was up for over a year with no issues, however since updating the Tor version it's been problematic at best. Thanks. Linux version 2.6.32-042stab125.5 (root(a)kbuild-rh6-x64.eng.sw.ru) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Tue Oct 17 12:48:22 MSK 2017 Tor version 0.3.1.9 :Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [over 16000001 similar message(s) suppressed in last 21600 seconds]

2 1