January 2017 - tor-relays - lists.torproject.org

TOR Relay performance issue
by Thomas Maurice 08 Jan '17

08 Jan '17

Hello all ! o/ It seems I am running into a performance issue with my relay, and I am not able to troubleshoot it, so I hope someone could point out something obvious I am missing! (for information, the relay is a 2vCPU, 2G RAM VM running on Scaleway) From what I observe from the graphs, my maximal CPU usage ceils at ~60%, and the load ceils at 1 eventhough the TOR daemon is aware I have 2 cores available, and I set the NumCPUs configuration option accordingly) First I tought that the network did not want to send me more traffic, but my graphs are way too regular to make this eventuality plausible, so I am pretty convinced that it is due to a lack of optimization on my side. (link to my graphs for reference http://www.noelshack.com/2017-01-1483803911-constancesurvingt.png this is a 1 hour snapshot, but it has been this constant for at least one day) My first hypothesis was that the daemon is running out of file descriptors, so I raised the limit that was in the defaults (doubled it actually, by editing /etc/init.d/tor like a pig, to test), but I did not observe any change in Grafana. It is supposed to be caped at 20MBps, and 25MBps burst so I doubt the limitation I am observing is enforced by the node itself. If anyone had any pointers I would be grateful! Cheers! -- Thomas

4 4

c23088def3e324089ed7bbe4b00082b251c06026
by mario 08 Jan '17

08 Jan '17

1 0

Raspberry Pi + Raspbian GNU/Linux 8.0 (jessie) + bind errors
by Kurt Besig 06 Jan '17

06 Jan '17

I just installed tor on a Raspberry Pi 3 Model B and can't get a relay to start unless I sudo. When I attempt to start tor as a non-privileged user I get a permissions error: Opening Jan 05 18:33:35.929 [notice] Opening OR listener on 0.0.0.0:443 Jan 05 18:33:35.930 [warn] Could not bind to 0.0.0.0:443: Permission denied Jan 05 18:33:35.930 [notice] Opening Directory listener on 0.0.0.0:80 Jan 05 18:33:35.930 [warn] Could not bind to 0.0.0.0:80: Permission denied Ideas on best method to bind these ports to tor on startup as non-root? Thanks

5 5

Raspberry Pi + Raspbian GNU/Linux 8.0 (jessie) + bind errors
by Kurt Besig 06 Jan '17

06 Jan '17

I just installed tor on a Raspberry Pi 3 Model B and can't get a relay to start unless I sudo. When I attempt to start tor as a non-privileged user I get a permissions error: Opening Jan 05 18:33:35.929 [notice] Opening OR listener on 0.0.0.0:443 Jan 05 18:33:35.930 [warn] Could not bind to 0.0.0.0:443: Permission denied Jan 05 18:33:35.930 [notice] Opening Directory listener on 0.0.0.0:80 Jan 05 18:33:35.930 [warn] Could not bind to 0.0.0.0:80: Permission denied Ideas on best method to bind these ports to tor on startup as non-root? Thanks sorry for the dup..

1 0

Faravahar acting up again / "Bad Gateway" while uploading descriptor
by anondroid 05 Jan '17

05 Jan '17

I just set up a handful of new relays, and all of them have something like the following in their logs: [WARN] http status 502 ("Bad Gateway") reason unexpected while uploading descriptor to server '154.35.175.225:80' [WARN] Received http status code 502 ("Bad Gateway") from server '154.35.175.225:80' while fetching... This appears to be related to the authority Faravahar. I know this has happened before but I wanted to make sure the proper people were aware of the issue. Thanks.

4 4

zwiebeln@online.de relays: MyFamily update required (was: [OrNetRadar] Contact: "<zwiebeln at online de>")
by nusenu 05 Jan '17

05 Jan '17

Hi zwiebeln, thanks for running so many tor exit instances and adding so many yesterday. Please do not forget to add your new relays to your MyFamily, your "old" relays had a proper MyFamily configuration. thanks, nusenu https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… +---------------------+-----------------+---------------+------+ | first_seen | IP | MyFamilyCount | exit | +---------------------+-----------------+---------------+------+ | 2016-04-11 21:00:00 | 178.17.170.179 | 25.0000 | 1 | | 2016-05-14 15:00:00 | 195.123.209.184 | 25.0000 | 1 | | 2016-07-03 15:00:00 | 178.17.170.179 | 25.0000 | 1 | | 2016-08-28 12:00:00 | 37.157.193.161 | 25.0000 | 1 | | 2016-09-10 14:00:00 | 37.157.193.161 | 25.0000 | 1 | | 2016-09-16 21:00:00 | 89.221.209.100 | 25.0000 | 1 | | 2016-09-18 12:00:00 | 37.157.196.97 | 25.0000 | 1 | | 2016-09-27 10:00:00 | 37.157.196.97 | 25.0000 | 1 | | 2016-09-27 10:00:00 | 89.221.209.100 | 25.0000 | 1 | | 2016-11-12 21:00:00 | 144.217.60.211 | 25.0000 | 1 | | 2016-11-12 23:00:00 | 213.32.55.239 | 25.0000 | 1 | | 2016-11-14 12:00:00 | 149.202.238.204 | 25.0000 | 1 | | 2016-11-15 15:00:00 | 144.217.60.239 | 25.0000 | 1 | | 2016-11-15 15:00:00 | 158.58.170.150 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.212 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.27 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.212 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.27 | 25.0000 | 1 | | 2016-12-05 16:00:00 | 51.15.53.83 | 25.0000 | 1 | | 2016-12-05 16:00:00 | 46.182.18.29 | 25.0000 | 1 | | 2016-12-05 16:00:00 | 51.15.53.83 | 25.0000 | 1 | | 2016-12-05 17:00:00 | 46.182.18.29 | 25.0000 | 1 | | 2016-12-05 17:00:00 | 46.182.18.214 | NULL | 1 | | 2016-12-16 20:00:00 | 88.151.99.224 | NULL | 1 | | 2016-12-18 18:00:00 | 185.14.29.129 | NULL | 0 | | 2016-12-18 22:00:00 | 149.202.238.204 | NULL | 0 | | 2016-12-18 22:00:00 | 144.217.60.239 | NULL | 0 | | 2016-12-18 22:00:00 | 144.217.60.211 | NULL | 0 | | 2016-12-18 22:00:00 | 213.32.55.239 | NULL | 0 | | 2016-12-18 23:00:00 | 158.58.170.150 | NULL | 0 | +---------------------+-----------------+---------------+------+ ornetradar(a)riseup.net: > 2016-12-18 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 0 | 21:41:51 | 149.202.238.204 | OVH SAS | fr | 444 | 81 | Linux | 0.2.8.11 | alsaceonionb | 1 > 1 | 0 | 21:26:02 | 144.217.60.239 | OVH SAS | ca | 444 | 81 | Linux | 0.2.8.11 | quebeconionb | 1 > 1 | 0 | 21:31:09 | 144.217.60.211 | OVH SAS | ca | 444 | 81 | Linux | 0.2.8.11 | montrealonionb | 1 > 1 | 0 | 21:36:53 | 213.32.55.239 | OVH SAS | fr | 444 | 81 | Linux | 0.2.8.11 | strasbourgonionb | 1 > 1 | 0 | 22:24:55 | 158.58.170.150 | Seflow S.N.C. D | it | 444 | 81 | Linux | 0.2.8.11 | milanoonionb | 1 > 1 | 0 | 17:42:44 | 185.14.29.129 | Serverius Holdi | nl | 9001 | 9030 | FreeBSD | 0.2.8.11 | humboldt | 1

2 5

Current pluggable transport recommendation
by Alexander Dietrich 05 Jan '17

05 Jan '17

Hi, the obfs2 pluggable transport was deprecated a while ago since it was easy to detect, but obfs3 was still considered safe, IIRC. Has anything changed here? I was just wondering if new bridges should only run obfs4, or if it's fine to run obfs3 at the same time. Best regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

2 1

High conntrack session count
by Sec INT 04 Jan '17

04 Jan '17

Hi Just had an issue on a 60mbps exit where conntrack sessions went over the usual 30000 limit - is this possible for a normal operating exit relay? Is there any default limit set on this or indeed is there a setting intorrc to control the number of sessions? Cheers Mark B Snaptor.co.uk (non commercial)

2 2

Tor Cloud
by Scott Ainslie 04 Jan '17

04 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm in the midst of relaunching Tor Cloud. I renamed it Onion Cloud as per a Tor Cloud suggestion. It's built upon Ubuntu 16.04.1 LTS (Xenial Xerus). I might add support for Ubuntu 14.04.5 LTS (Trusty Tahr) but in the meantime I'm concentrating upon supporting Ubuntu 16.04.1 LTS (Xenial Xerus). I prioritized reducing the amount of needless unsecured communication aside from inheriting all the properties of the original and ensuring that it's up-to-date. I added support to the Amazon Machine Images (AMI) for HTTP Secure protocol-supporting repositories because the repositories Canonical maintains don't support it. I hope Canonical adds support to its repositories in due time. Tor Cloud didn't support HTTP Secure protocol-supporting repositories but I feel it's crucial to add explicit support for it and adopt a defense-in-depth attitude in addition to reliance upon GnuPG detached digital signatures. I'm updating the default GnuPG configuration to add Transport Layer Security support. I plan to add support for Microsoft Azure and Google Compute Engine. Microsoft Azure has a command-line interface that I can use to add support for it as does Google Compute Engine. I'm afraid the cost of Microsoft Azure or Google Compute Engine is outright prohibiting being able to add support at this time. I also bought a domain name and set up 3 Domain Name Servers for it. It supports Internet Protocol version 4 and Internet Protocol version 6 and its Domain Name Server zone is also signed using Domain Name System Security Extensions. I'm still in the process of debugging and updating the original shell scripts and I'd like to be certain that it's robust. I'm intending to publish the shell scripts on GitHub in a fortnight but I'm hoping I can publish it before long. I'm eager to begin encouraging contributors to help refine it! - -- Scott Ainslie <scott(a)scottainslie.me.uk> -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYbOJOAAoJEM18vpeSzTzCHUEP/12tjHqbAF2SYSKrtk/c7B0f BvvXuOn7ZDSbC48RHiKar8PsGTtbk8ofjSSi85sZhkJY0CgIjC6G31Hh5YUOM+EI GyKt2FBtPcbO6n3aJLKLB2nXHm3kxkXShFNhyz3TNDYre5jrHRUNmxTeRh+yDcQm +t3xacR2BOfeblS3SzFjXPGyoSeuW7n+LiOwjm7g50if2Vb8eqV2TzfzA5Q721Jc m+0Yg7GuXLrye70wAIYMdEFvvpeacQkGSamYNpF6gCVe/zkfsXxJBxWeMW9Vp2G7 C0W1FKtol/HXpw7SdFirM8/54D8ZUXoDLlLHYFYZ32iOslVXugE/BRePb4Yw7jAZ eMsHr7jxPVid6iK5Ez+YSw3uDaubYjri/3WEmUaO4/QzztW5LmEuF1XcIRFriN3G mZZ4HQ09+IZC6qtIcB3R+8s+1lHHZzKjgAueu1yeCd4evs9Ski+MgDdogFppi9Yh EeevgIv5XSwdez/C0r25G8Repm2AkTstTBaF5/Lc5rEFYb4CEQEICXFCMYZbk78d IV6zAF31sCtbYvSCWz+0RBszimyWoOHPCFIvQ43yYouZvZq3MMjn7RAj0oVhwvcW +lrpaqMCjsm7dnRyqKkYAh4DmSBmFFSQgB4bXA6eZJgApGZodK/IAQlFIcB/k2hb SqCvYuSMGDW61ZiRnCK9 =MJdn -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Speed up of reconnections after IP Address change
by balbea16 03 Jan '17

03 Jan '17

'tor service start' disconnects all connections, START uses the new IP address. Which is important. I am not sure if Sighup does the same. I assume it only reloads the config file. Any ideas?

1 0