- tor-relays - lists.torproject.org

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 06 Jan '17

06 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

consensus-health
by Felix 03 Jan '17

03 Jan '17

https:// consensus-health.torproject.org/ (observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00) shows * dannenberg: Missing entirely from consensus * faravahar: Missing Signature! Valid-after time of auth's displayed consensus: 2017-01-03 15:00:00 * moria1: Sees only 2620 relays running Is https:// lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html ok ? -- imho - like always

2 1

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

03 Jan '17

Hi ThereI've just written a simple bash script which verifies (in a while loop) every 2 minutes if the OR address has been changed by my ISP. If so, it stops and then restarts the Tor service again. Then it sleeps for 24 hours and starts the 2 minute loop again. Not very sophisticated, but it might work. Mike

2 1

how to generate relay keys manually (before actually running the relay)
by nusenu 03 Jan '17

03 Jan '17

>> Tipp: If you are planing to grow beyond your 31 relays I recommend >> you preemptively generate the keys for your upcoming relays so you >> don't have to touch all other relays everytime you add a single >> relay (to the MyFamily line). > How do you pregenerate keys? Id be interested as Im spinning up > quite a few soon create a folder per tor instance: mkdir future-relay1 future-relay2 ... then invoke tor manually (this will just generate keys and exit after that): tor --PublishServerDescriptor 0 --orport auto --list-fingerprint --datadirectory future-relay1 --Log "err stdout" tor --PublishServerDescriptor 0 --orport auto --list-fingerprint --datadirectory future-relay2 --Log "err stdout" ... In these folders you will then find the fingerprint that you can use in MyFamily, so you don't have to touch your existing relays anymore once you actually use these generated keys on new relays. Make sure you take care of filesystem permissions when using these keys on the actual relay.

2 1