- tor-relays - lists.torproject.org

What does this log message mean ? : Starting with guard context "default"
by Toralf Förster 08 Feb '17

08 Feb '17

3 3

assign_to_cpuworker failed
by diffusae 07 Feb '17

07 Feb '17

Hello! What does this warning mean? "Jan 13 09:31:49.000 [warn] assign_to_cpuworker failed. Ignoring." Do I need to reduce the number of connection to the relay or could I ignore this message? Regards,

5 21

no ipv6 traffic from/to relays ?
by Toralf Förster 07 Feb '17

07 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Switching from 0.2.9.9 to 0.3.0.3-alpha now let 1/3 of my outgoing network traffic to exit ports (of my Tor exit relay) being ipv6. OTOH there's more or less no ipv6 traffic from/to other relays. Is this (another ipv6) bug/issue in Tor or just expected ? - -- Toralf PGP: C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iHYEAREIAB4FAliWTYAXHHRvcmFsZi5mb2Vyc3RlckBnbXguZGUACgkQxOrN3gB2 6U7R/QD+Nr4q1CHmhVKgrUrqSp/fEXCEnLnpSfO+njxRdnICbOIA+wSwB02bIOgB mWS13po62pXdO8r3QJiiz5Q7G8ryvtkt =1Mzz -----END PGP SIGNATURE-----

4 8

Re: [tor-relays] [OrNetRadar] AS: "2267921 ONTARIO LTD" - Linux (6)
by nusenu 06 Feb '17

06 Feb '17

> New relays added on 2017-02-01 in AS "2267921 ONTARIO LTD" > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | CC | ORp | Dirp |Version | ContactInfo | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 0 |01:02:35| 64.137.243.13 | ca | 9001 | 9030 |0.2.8.8 | noah.holland(a)aol.com | phenomenamomentaryh | 1 > 1 | 0 |02:24:58| 64.137.172.121 | ca | 9001 | 9030 |0.2.8.8 | enriquehanson56(a)gmail.com | UwFrNxQgYtBeMv | 1 > 1 | 0 |04:10:09| 45.62.244.240 | ca | 9001 | 9030 |0.2.8.8 | kmjapiji(a)mail.com | 9U5Cs7gu3XTORY | 1 > 1 | 0 |04:17:13| 45.62.252.66 | ca | 9001 | 9030 |0.2.8.8 | jjzwpy(a)yahoo.com | 8z4w2t6qteADFfb6 | 1 > 1 | 0 |12:45:39| 64.137.197.233 | ca | 9001 | 9030 |0.2.8.8 | malvina.maybury(a)gmail.com | CHWMSRVU | 1 > 1 | 0 |13:20:17| 64.137.189.77 | ca | 9001 | 9030 |0.2.8.8 | pwcrack(a)pwcrack.com | CACpwcrackgnt4 | 1 > Fingerprints: > FCAA8608123018476C576AE44AFBC2367D3333AB,653BDEEB516FD16917A45A2DD44272F59C765EF5,82B6083CA4FCC777320CE03EA45BB9380A45A4E7,9D0CBF2C789B9C88F1FE403DA3D5B849B182EAD4,56879AF8A29B1354ED751B26E2D4D3F3C44F2096,FA94C4060AD0BBE913676F090F6BA6706B97F205 > someone trying hard to look different? :)

1 0

Re: [tor-relays] Squalala tor relays: please update 'MyFamily' in your torrc
by nusenu 06 Feb '17

06 Feb '17

Hi BPM Squalala, thanks for adding two more relays, please do not forget to update your MyFamily setting. thanks, nusenu https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… +---------------------+-------------+--------------+ | first_seen | nickname | eFamilyCount | +---------------------+-------------+--------------+ | 2016-09-18 12:00:00 | RedOctober | 3 | | 2016-09-29 16:00:00 | 5OfNovember | 3 | | 2016-12-07 22:00:00 | May68 | 3 | | 2017-02-02 16:00:00 | 9OfDecember | NULL | | 2017-02-03 19:00:00 | 14OfJuly | NULL | +---------------------+-------------+--------------+

1 0

Problem upgrading Tor to 0.2.9.9 on Raspbian (Debian Jessie)
by fr33d0m4all 03 Feb '17

03 Feb '17

Hi, this is not really a Tor issue, but I'd like to know if there is someone else like me that is having problems upgrading his Tor installation to the latest version on its Raspberry (running Raspbian based on Debian Jessie): # apt list --upgradable -a Listing... Done tor-geoipdb/stable 0.2.9.9-1~d80.jessie+1 all [upgradable from: 0.2.9.8-2~d80.jessie+1] tor-geoipdb/now 0.2.9.8-2~d80.jessie+1 all [installed,upgradable to: 0.2.9.9-1~d80.jessie+1] tor-geoipdb/stable 0.2.5.12-4 all tor-geoipdb package could be upgrade but the tor package on which it depends is not available: # apt install tor-geoipdb Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: tor-geoipdb : Depends: tor (>= 0.2.9.9-1~d80.jessie+1) but 0.2.9.8-2~d80.jessie+1 is to be installed E: Unable to correct problems, you have held broken packages. Thank you in advance for any answer, Fr33d0m4All -- _____________________________________________________________ PGP Key: 0DA8 7293 D561 3AEE A3C0 7F63 101F 316A F30E ECB4 IRC Nick: fr33d0m4all (OFTC & Freenode) _____________________________________________________________

4 4

Minimum port 80 and 443 exit policy
by Mass Tor 03 Feb '17

03 Feb '17

Hey all, I was wondering what the minimum exit policy was (wrt port 80 and 443) for a Tor exit relay. I cant find any documentation about the minimum exit policy. Is it possible to have an exit relay exit only to a /16 or a /8 on port 80 and 443? I've tried having an exit policy that allows exiting to just a /16 on port 80 and 443 and it seems to not stick. Best

4 3

blazingvpn tor relays: please specify 'MyFamily' in your torrc
by nusenu 01 Feb '17

01 Feb '17

Hi blazingvpn tor relay operator, thanks for adding 4 more tor relays to the network! Please do not forget to set the MyFamily parameter in your torrc configuration to tell clients your relays belong to a single operator. If you need help with the MyFamily option let us know. thanks, nusenu +------------+-----------------+----------------+ | first_seen | IP | eMyFamilyCount | +------------+-----------------+----------------+ | 2016-12-17 | 163.172.190.249 | NULL | | 2016-12-31 | 108.61.128.176 | NULL | | 2016-12-31 | 51.15.47.106 | NULL | | 2016-12-31 | 51.15.58.152 | NULL | | 2017-01-06 | 185.163.45.249 | NULL | +------------+-----------------+----------------+

6 19

The Onion Box v3.2: Web Interface for your Tor relay
by theonionbox＠gmx.com 31 Jan '17

31 Jan '17

6 8

[OT] VPNGate needs nodes
by grarpamp 31 Jan '17

31 Jan '17

For those of you offering more than one service on your box, an example among many other circumvention / overlay networks you might like to support... http://www.vpngate.net/

2 1

Run a bridge or relay?
by Sebastian Hoffmann 29 Jan '17

29 Jan '17

Hi all, I've been running a relay for several months now. In the last weeks I read a bit about the censorship in turkey and asked myself how to help if normal Tor services are blocked. Obfs4 could help. But on the pages from torproject about running a relay you are told to run a relay if you can and a bridge only under certain circumstances. But... are there enough bridges? If I were the turkey administration, I would try to block all the bridges I could find one by one. So... do we really have enough bridges out there?

3 2

Updates removes status flags
by a tor op 29 Jan '17

29 Jan '17

Hi When a tor admin updates a tor node, what is the reasoning for punishing the status by removing flags like the guard flag? The node may have been up for months on end without issues and goes down for a few minutes during install and restart and comes up with a newer version, hence it is clearly updated. And the guard flag goes away. Doesn't seem really appropriate. Unless it's to indicate caution due to new version perhaps not being stable. But then that's what you do pre-prod testing in-house for. A TOR bridge op

3 3

ae rises and rises
by Felix 29 Jan '17

29 Jan '17

Please check out https:// metrics.torproject.org/userstats-relay-country.html?start=2015-10-22&end=20… vs https:// metrics.torproject.org/userstats-relay-country.html?start=2015-10-22&end=20… -- I this cool or not?

3 3

Atlas: Short term bandwidth charts missing ?
by mistral.relay＠posteo.net 28 Jan '17

28 Jan '17

Maybe it's just me - but I tried three different browsers and usually can't see the short term usage charts on Atlas, i.e. 3-days and 1 week bandwidth charts are usually just blank. Two random examples where I can't see the charts (but there is data; monthly and yearly charts showing up quite well): https://atlas.torproject.org/#details/F3F8B1A79C6781609B443CF0C1A130C85EB60… https://atlas.torproject.org/#details/7D278652898C38878F51D93969EB88C497BFB… Sorry, if this is my local issue but I just can't find the reason for it...

4 6

Please enable IPv6 on your relay!
by Moritz Bartl 28 Jan '17

28 Jan '17

Hi! We still have a depressingly low number of relays that support IPv6 (currently only ~120 of ~1900 relays). If your host supports IPv6, please enable it, especially if you run an exit! This has to be done explicitly. https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto In short, you add: ORPort [IPv6::address]:port IPv6Exit 1 ExitPolicy reject6 *:* (or a more open exit policy respectively) Thanks! -- Moritz Bartl https://www.torservers.net/

30 42

Fwd: netbackup.gs tor relays: please specify 'MyFamily' in your torrc
by netbackup.gs 28 Jan '17

28 Jan '17

3 5

Which is best for Tor: libevent v.2.0.22 or v2.1.8?
by Steve Snyder 26 Jan '17

26 Jan '17

With the long-awaited v2.1.8 of LibEvent recently released, this brings up the question: which is more suitable for use with contemporary versions of Tor, the older v2.0.22-stable or the shiny-new v2.1.8-stable? Thanks.

1 0

Fwd: US-CERT Avalanche Notification INC000010
by Monkey Pet 24 Jan '17

24 Jan '17

I received the following email from my ISP, the IP belongs to the tor exit node. I am wondering if the DHS is sending it out to all tor exit nodes? We received a notice from Homeland Security that a device using your current IP address is infected the Avalanche Malware. The full details are below. Please run antivirus and network security software on all your devices immediately. Thank you, ISP A trusted third party notified the Department of Homeland Security United States National Cybersecurity & Communications Integration Center (NCCIC) that one or more machines on your network was infected with malware associated with the Avalanche botnet infrastructure during December 2016. Avalanche is a large global network hosting infrastructure used by cyber criminals to conduct phishing and malware distribution campaigns and money mule schemes. A system infected with Avalanche associated malware may be subject to malicious activity including the theft of user credentials and other sensitive data, such as banking and credit card information. Some of the malware has the capability to encrypt user files and demand a ransom be paid by the victim to regain access to those files. In addition, the malware may allow criminals unauthorized remote access to the infected computer. Infected systems could be used to conduct distributed denial-of-service (DDoS) attacks. For additional information, please see the following US-CERT Technical Alert (TA16-336A): https://www.us-cert.gov/ncas/alerts/TA16-336A

2 1

Network is unreachable?
by niftybunny 24 Jan '17

24 Jan '17

xxx@xxxx:~# wget https://www.torproject.org/dist/tor-0.2.9.9.tar.gz converted 'https://www.torproject.org/dist/tor-0.2.9.9.tar.gz' (ANSI_X3.4-1968) -> 'https://www.torproject.org/dist/tor-0.2.9.9.tar.gz' (UTF-8) --2017-01-23 22:12:32-- https://www.torproject.org/dist/tor-0.2.9.9.tar.gz Resolving www.torproject.org (www.torproject.org) 2620:0:6b0:b:1a1a:0:26e5:4810, 2001:858:2:2:aabb:0:563b:1e28, 2001:41b8:202:deb:213:21ff:fe20:1426, ... Connecting to www.torproject.org (www.torproject.org)|2620:0:6b0:b:1a1a:0:26e5:4810|:443... failed: Network is unreachable. Connecting to www.torproject.org (www.torproject.org)|2001:858:2:2:aabb:0:563b:1e28|:443... failed: Network is unreachable. Connecting to www.torproject.org (www.torproject.org)|2001:41b8:202:deb:213:21ff:fe20:1426|:443... failed: Network is unreachable. Connecting to www.torproject.org (www.torproject.org)|2a01:4f8:172:1b46:0:abba:5:1|:443... failed: Network is unreachable. Connecting to www.torproject.org (www.torproject.org)|82.195.75.101|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://dist.torproject.org/tor-0.2.9.9.tar.gz [following] converted 'https://dist.torproject.org/tor-0.2.9.9.tar.gz' (ANSI_X3.4-1968) -> 'https://dist.torproject.org/tor-0.2.9.9.tar.gz' (UTF-8) --2017-01-23 22:12:36-- https://dist.torproject.org/tor-0.2.9.9.tar.gz Resolving dist.torproject.org (dist.torproject.org) 2620:0:6b0:b:1a1a:0:26e5:4810, 2001:41b8:202:deb:213:21ff:fe20:1426, 2a01:4f8:172:1b46:0:abba:5:1, ... Connecting to dist.torproject.org (dist.torproject.org)|2620:0:6b0:b:1a1a:0:26e5:4810|:443... failed: Network is unreachable. Connecting to dist.torproject.org (dist.torproject.org)|2001:41b8:202:deb:213:21ff:fe20:1426|:443... failed: Network is unreachable. Connecting to dist.torproject.org (dist.torproject.org)|2a01:4f8:172:1b46:0:abba:5:1|:443... failed: Network is unreachable. Connecting to dist.torproject.org (dist.torproject.org)|2a01:4f8:211:6e8:0:823:2:1|:443... failed: Network is unreachable. Connecting to dist.torproject.org (dist.torproject.org)|38.229.72.16|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 5534005 (5.3M) [application/x-gzip] Saving to: 'tor-0.2.9.9.tar.gz' tor-0.2.9.9.tar.gz 100%[===================================================================================================================>] 5.28M 9.89MB/s in 0.5s 2017-01-23 22:12:41 (9.89 MB/s) - 'tor-0.2.9.9.tar.gz' saved [5534005/5534005] Is this normal behaviour? niftybunny abuse(a)to-surf-and-protect.net

4 12

Re: [tor-relays] 'MyFamily' .... torworld.org
by Paul 20 Jan '17

20 Jan '17

Hey, why don’t you just explain to the relay mailing list what it is all about..? Why are you different to "abuse [AT] torworld.org " and where are you probably the same ? What is your idea (business model) behind , why are supporting Tor in such a heavy way ? What are your driving forces...? Its not a must, but it would be less suspicious for somebody with you size! Thanks and Regards - to whom ever - Paul Am 19.01.2017 um 05:22 schrieb e: > Thanks for the heads up Paul.

3 3

Middle relay still an useful contribution?
by Ortez 20 Jan '17

20 Jan '17

Hello tor relay operators, I'm thinking about creating another tor middle relay, but i'm not sure if this is still a good contribution to the tor network. When i'm looking at some of the relay stats out there, there are so many middle relays, which getting almost no traffic. If i purchase a server, i want to make sure the money i will spend every month will make a difference. I know, an exit node may be the better option and those will get a lot of traffic, but i'm not very happy with the consequences which i may face. It's also very difficult to find a provider, which is cool with an exit node. Whats your opinion?

7 7

Proton now takes Tor
by Gumby 19 Jan '17

19 Jan '17

Nice to finally see this... "The encrypted email provider announced Thursday it will allow its users to access the site through the Tor anonymity service. The aim is to allow its more than 2 million users access the provider by taking "active measures to defend against state-sponsored censorship," such as government-mandated blocks at the internet provider level. Users of the Tor Browser can now access the site at https://protonirockerxow.onion. "

1 0

SIGHUP causing obfs warning/disabling
by Geoff Down 19 Jan '17

19 Jan '17

Hi, I sent a SIGHUP to the tor process after altering the torrc and got this effect: Jan 19 00:47:42.000 [notice] Tor 0.2.9.8 opening log file. Jan 19 00:47:55.000 [warn] Server managed proxy encountered a method error. (obfs3 Could not set up listener (0.0.0.0:xxxxx) for 'obfs3' (Address already in use).) Jan 19 00:47:55.000 [warn] Managed proxy at '/usr/bin/obfsproxy' failed the configuration protocol and will be destroyed. It did it again when I restored the torrc and SIGHUPed again. Obfs3 is still running and listening afaict: tor 17356 0.0 0.2 49944 1736 ?? S 20Dec16 0:13.04 /opt/local/Library/Frameworks/Python.... Python 17356 tor 3u IPv4 0x02eb32a4 0t0 TCP *:xxxxx (LISTEN) Bug or !Bug ? GD -- http://www.fastmail.com - mmm... Fastmail...

3 6

exitnodes blocking services
by not important 18 Jan '17

18 Jan '17

Hey all, Got a question here, I'm running an exit node from a home network that uses play station network, Facebook and a few other service. So my issue/question is why are these service getting blocked on my end? I'm assuming that my ip is getting blocked but wouldn't that mean that people using my exit node would be blocked to those websites as well? what can i do to resolve this issue? maybe I'm missing some technical aspect? thanks! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFh10ZkBEAC3QTfDVUmKlKl5JNvy7kHulRj7nXYeYEywyXo5zsYsvWeCRYit WqwOr8PgGVO+jmXSxkXxjnGvXF7Kr1qZRHy/1hJxwFztlsgzkYzJOQYqB5Wpgxgf tpkZmY/uOzg61ppvSF8OKteal+jZnPEwGtGr6MNEc4WZecE99NA3tQ9kiqr0wHJE UstgiFv1DV4ju/nqCoaplVCy2LVdTq/IPXXJPozUYYM4U5S6qNPWgg8NKUUAPkkZ kJrgd2PD0qayU5HxO9lIHlwt1f9dp0iwXafXF4DkivMmpipoKB7e6eS+LYYTHQVz rmn+Goco7m34TsBua0ltjY5KDz7Nlts5bOFOYgCLrnpJJggACPetCr1NFQVbkaLb qpZ8hRkuJl5fKR/55lhLMSC7Bh85b4UQioS83ChyyY3dgNuXzss41/gn7sp0VUuA oQg+YYia3vWmOaBSXlQmM8ukw9QcMiVje4qlUaZjsCcNKwRCEX6YvcY1X8Yzm6uv yycPvroTIiJE1YZOVRj2oGSqNftZWtTnebVEveIezF/tX7Tadf6xq6kaQdUZzbAv tX+O/jOTGfo/8XECXPrLiPXlwY3ZrloXMr1QSBJQxZoCkfuDsi9Lek3SvWmxrQuM 0q66bk4k7LrO7e0lNueLSmna4OZFih/FUFwAq+bH6SciF9eOxm6NOPrnXwARAQAB tC9mcmVkYSAoc3RyZW5ndGggaW4gbnVtYmVycykgPEZyZWRhQHNpZ2FpbnQub3Jn PokCNwQTAQgAIQUCWHXRmQIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDi hi2oPd1kcz6hEACyDgzf+L0OpB9Znsx7EEt8N1/zGyzGQoL/MQVsxMiJl/J3f7zV p7EJ3u4PGlETZAHFc2mVWc9FZndPgJIHS491g8sglJqPLhe7c+GjbACCGeb8XtQr kMTkFl2xcM0fv6XQTkRoGlQrnVMlB35DbFgjk7You3X1eAH3ZYe1NzsSaek9qeol OqKSa/J2mNiwKtaSW/NY5cD2cScuu4pqVwNb6Ya1OamvrCobRvi9rnnwGT148rpe I9hDrK2q5n5sz3rzWi7IT0Yv3ao0JkjAZHGuHeLvJLzv3R29RleTITd728LEWbxk xVTvcgl4u7lrZuqmhcaB2xDYvHDLx2PKyDxRSW3R/oahTCMVm1gjYnIB+L1aHPMZ ulxpKK0rylp2sNGgG8Kr/aasDENNgoxo76+qvVixIJWXovJruvlCMHeyySE9Tn14 rOoQICuOaEiMkUqpnEWqyOEJQs2Ky8AeRiQLAj+Il3Ed0fG0qHxosuWm/EAztKWH 329XAaaILDMeqp5Y4niBRq3at7QKb3LABpDI8/wqn9n4y7koaLQGpwGQRkbJszgh JqGJ3Bwh4B4Absze4gzvCYyh3mt7dwgo6zvG1PJ8x1I/D+TtUkUdQBojXf5YteUY OTN9IPjXaBlm9hbO2D0fXWdaz9QJEh3nSSqWd9/FU9w+6ACZz8ZeJivRtrkCDQRY ddGZARAA3o4NQV87nvPVbPp8NzPqQoRt+TdDVzcq10fHHAs2vIlgNPqQmMLiw/a6 Nsx4oFXuaCdyvQ6QsWKTOH33Ui0q+SrCdr5vVUQT6OJgMt4dqWv39zSXZeDFuy9U bmsd1ym7MGcRgDrvMHYdiz7AP3C1zmaCrjB8yV4oARVwKOafD5VznJOtX17c08M8 x+EQzypwgGer0vT3OzeTbHqWd491IOfdD0ejbapTLkOMPblPriOwtkh+lcC9QXD+ cb7Y+/79KjEXFTXr97R66AXmlkeWSnqWqZbTWrwp5nn5OpkgnpXqSVynIafAwePg KZCsVSCwMeo4aguj8znyUCd60lbc/WPhXnjmYXBHYXsUf4OMCa8P/yBkiC6jyYA/ zHKeJZgR2Nlu945flszQjc115tVo1dWqdxmB3cq9TBVu+6Npzgz28TD/I6NUekyE Gv/ESwbI3b7vbW/dBDiL6r8aGYFTvW+EmfCajOjZHT93hiz83JIpHOrIhibnGiMA bja8Lk6s3WZ5LmA03T2PhKj3Mo0Rx8FXl/+7GU8H3mYHJwpHSSoBuvswDOH6SQVB Yb+ckBzloiQ+cccIWuDItskc0Jeq1MB+FPgCfscT5B5545euT8Sq0aNHs4D5gRey 1e0X8eCAXZsyuuXpnOL8+8ty3WjwMmR8mgtjL4wXxP3CXPnvYFkAEQEAAYkCHwQY AQgACQUCWHXRmQIbDAAKCRDihi2oPd1kc22EEACwfwplUbvVtflOh2MiOUWnXGHO xTff7RjITk0NpK/a4bPTKOWdWKenTePSy8UCYIUK2u8dH6RrAq7L/OpoysltvJi3 ktKpkjr5mpXtywd0HKOEWoHrIj+Z2ZDubDVe9/cPYBuZdzaqxQ+P+Dc3NNh53RCf iXxbftk1D86jjfKoBj1aGPEPUSQHpW1Iw/Kh5E+dKN02oALjUudyjfv2byJ+niqO qbkHgIuUsOTWaWKwgMqgTbjW4NeMj+7DJcskM8NUnBLjiT+WG1wW8Teom/PakD32 ZFt5bIO7xVE4NP9wiFxH/dlXuxQLyg0TON2xUrBtN+/LRGJVQvl6iglmf1KxAkv9 maSGBFXtZY5tyA2UBwFJZ2D6XjeaVdFfIfa5rcUY3PTwt8kECivr5AHN3qrz3wuS QkHb/HQm7SeMZs3h02VEfHhmGxv98TwRF1rSCXRBORLDnY7Bh5WTdaR9CoDTU0aw Bvo4vHH8EODU7bJwfCuaCprzIP/Vbl+PYxU5W180pd/XaQXk9XERcn86b9n9q4Ea 9+CqXIRGal/DLBZRjmq8xN33dHfMnbP+N2ik09Zz0zdZHVsCQRK3xFFIwK9OpFdx Xa/drJTa58B7rogm4DBXgI63hjDZN+FZTpxRpKWHstfStVYQk8Kfu2hir1e6FF2s /Ijrx6DPmuYb/0e0Kg===Fv5C -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFh10ZkBEAC3QTfDVUmKlKl5JNvy7kHulRj7nXYeYEywyXo5zsYsvWeCRYit WqwOr8PgGVO+jmXSxkXxjnGvXF7Kr1qZRHy/1hJxwFztlsgzkYzJOQYqB5Wpgxgf tpkZmY/uOzg61ppvSF8OKteal+jZnPEwGtGr6MNEc4WZecE99NA3tQ9kiqr0wHJE UstgiFv1DV4ju/nqCoaplVCy2LVdTq/IPXXJPozUYYM4U5S6qNPWgg8NKUUAPkkZ kJrgd2PD0qayU5HxO9lIHlwt1f9dp0iwXafXF4DkivMmpipoKB7e6eS+LYYTHQVz rmn+Goco7m34TsBua0ltjY5KDz7Nlts5bOFOYgCLrnpJJggACPetCr1NFQVbkaLb qpZ8hRkuJl5fKR/55lhLMSC7Bh85b4UQioS83ChyyY3dgNuXzss41/gn7sp0VUuA oQg+YYia3vWmOaBSXlQmM8ukw9QcMiVje4qlUaZjsCcNKwRCEX6YvcY1X8Yzm6uv yycPvroTIiJE1YZOVRj2oGSqNftZWtTnebVEveIezF/tX7Tadf6xq6kaQdUZzbAv tX+O/jOTGfo/8XECXPrLiPXlwY3ZrloXMr1QSBJQxZoCkfuDsi9Lek3SvWmxrQuM 0q66bk4k7LrO7e0lNueLSmna4OZFih/FUFwAq+bH6SciF9eOxm6NOPrnXwARAQAB tC9mcmVkYSAoc3RyZW5ndGggaW4gbnVtYmVycykgPEZyZWRhQHNpZ2FpbnQub3Jn PokCNwQTAQgAIQUCWHXRmQIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDi hi2oPd1kcz6hEACyDgzf+L0OpB9Znsx7EEt8N1/zGyzGQoL/MQVsxMiJl/J3f7zV p7EJ3u4PGlETZAHFc2mVWc9FZndPgJIHS491g8sglJqPLhe7c+GjbACCGeb8XtQr kMTkFl2xcM0fv6XQTkRoGlQrnVMlB35DbFgjk7You3X1eAH3ZYe1NzsSaek9qeol OqKSa/J2mNiwKtaSW/NY5cD2cScuu4pqVwNb6Ya1OamvrCobRvi9rnnwGT148rpe I9hDrK2q5n5sz3rzWi7IT0Yv3ao0JkjAZHGuHeLvJLzv3R29RleTITd728LEWbxk xVTvcgl4u7lrZuqmhcaB2xDYvHDLx2PKyDxRSW3R/oahTCMVm1gjYnIB+L1aHPMZ ulxpKK0rylp2sNGgG8Kr/aasDENNgoxo76+qvVixIJWXovJruvlCMHeyySE9Tn14 rOoQICuOaEiMkUqpnEWqyOEJQs2Ky8AeRiQLAj+Il3Ed0fG0qHxosuWm/EAztKWH 329XAaaILDMeqp5Y4niBRq3at7QKb3LABpDI8/wqn9n4y7koaLQGpwGQRkbJszgh JqGJ3Bwh4B4Absze4gzvCYyh3mt7dwgo6zvG1PJ8x1I/D+TtUkUdQBojXf5YteUY OTN9IPjXaBlm9hbO2D0fXWdaz9QJEh3nSSqWd9/FU9w+6ACZz8ZeJivRtrkCDQRY ddGZARAA3o4NQV87nvPVbPp8NzPqQoRt+TdDVzcq10fHHAs2vIlgNPqQmMLiw/a6 Nsx4oFXuaCdyvQ6QsWKTOH33Ui0q+SrCdr5vVUQT6OJgMt4dqWv39zSXZeDFuy9U bmsd1ym7MGcRgDrvMHYdiz7AP3C1zmaCrjB8yV4oARVwKOafD5VznJOtX17c08M8 x+EQzypwgGer0vT3OzeTbHqWd491IOfdD0ejbapTLkOMPblPriOwtkh+lcC9QXD+ cb7Y+/79KjEXFTXr97R66AXmlkeWSnqWqZbTWrwp5nn5OpkgnpXqSVynIafAwePg KZCsVSCwMeo4aguj8znyUCd60lbc/WPhXnjmYXBHYXsUf4OMCa8P/yBkiC6jyYA/ zHKeJZgR2Nlu945flszQjc115tVo1dWqdxmB3cq9TBVu+6Npzgz28TD/I6NUekyE Gv/ESwbI3b7vbW/dBDiL6r8aGYFTvW+EmfCajOjZHT93hiz83JIpHOrIhibnGiMA bja8Lk6s3WZ5LmA03T2PhKj3Mo0Rx8FXl/+7GU8H3mYHJwpHSSoBuvswDOH6SQVB Yb+ckBzloiQ+cccIWuDItskc0Jeq1MB+FPgCfscT5B5545euT8Sq0aNHs4D5gRey 1e0X8eCAXZsyuuXpnOL8+8ty3WjwMmR8mgtjL4wXxP3CXPnvYFkAEQEAAYkCHwQY AQgACQUCWHXRmQIbDAAKCRDihi2oPd1kc22EEACwfwplUbvVtflOh2MiOUWnXGHO xTff7RjITk0NpK/a4bPTKOWdWKenTePSy8UCYIUK2u8dH6RrAq7L/OpoysltvJi3 ktKpkjr5mpXtywd0HKOEWoHrIj+Z2ZDubDVe9/cPYBuZdzaqxQ+P+Dc3NNh53RCf iXxbftk1D86jjfKoBj1aGPEPUSQHpW1Iw/Kh5E+dKN02oALjUudyjfv2byJ+niqO qbkHgIuUsOTWaWKwgMqgTbjW4NeMj+7DJcskM8NUnBLjiT+WG1wW8Teom/PakD32 ZFt5bIO7xVE4NP9wiFxH/dlXuxQLyg0TON2xUrBtN+/LRGJVQvl6iglmf1KxAkv9 maSGBFXtZY5tyA2UBwFJZ2D6XjeaVdFfIfa5rcUY3PTwt8kECivr5AHN3qrz3wuS QkHb/HQm7SeMZs3h02VEfHhmGxv98TwRF1rSCXRBORLDnY7Bh5WTdaR9CoDTU0aw Bvo4vHH8EODU7bJwfCuaCprzIP/Vbl+PYxU5W180pd/XaQXk9XERcn86b9n9q4Ea 9+CqXIRGal/DLBZRjmq8xN33dHfMnbP+N2ik09Zz0zdZHVsCQRK3xFFIwK9OpFdx Xa/drJTa58B7rogm4DBXgI63hjDZN+FZTpxRpKWHstfStVYQk8Kfu2hir1e6FF2s /Ijrx6DPmuYb/0e0Kg===Fv5C -----END PGP PUBLIC KEY BLOCK-----

8 10

Good Bad ISP - update required
by Petrusko 18 Jan '17

18 Jan '17

Hey, Sorry to disturb about that... I'm trying to find a way to update/add informations on this page : https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs I have mailed a vps provider about running Tor relays on their DC, and there's no problem about running it. About exit node, it can be (like others) more dangerous if they have a lot of abuse mails (for sure it can be solved, but I'm not an expert with that :p) So it's possible to update informations on this page... If there's a mail address to inform ? Or here on this mailing list ?... Thx :) -- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

1 0

Some problems with new Exit Node
by Alan 17 Jan '17

17 Jan '17

So I bit the bullet and started running an Exit Node (Andromeda), still early days with a few problems, namely:- # It hasn't been given a Stable flag yet. # Some problem with dns resulting in [WARN] eventdns: All nameservers have failed - i've switched the dns to 8.8.8.8, only seen that error once since # The Consensus Weight was gaining nicely and reached over 7,000 but now has dive bombed to just 20, with that the speed dropped from ~50mbps to ~5mbps https://atlas.torproject.org/#details/FDB4FC238F13E7FEC99D025DB8B89A636EFC1… Is this all normal or something i've overlooked? Alan

4 4

Uptime missing from Arm
by Alan 17 Jan '17

17 Jan '17

I have 3 relays running but on Arm only one shows the uptime. Also the Averages it keeps are way off. Alan.

11 27

FW: What's a "useful" mailing list contributor? (was Re: What's a "useful" relay?)
by Rana 17 Jan '17

17 Jan '17

Wow. I offer to maintain a FAQ for small relays and in return I get this. Unsubscribed. On 3 Jan 2017, at 17:57, Rana <ranaventures(a)gmail.com <mailto:ranaventures@gmail.com> > wrote: @teor I hereby volunteer to maintain a FAQ for operators of small relays (or noob operators). Which means I would be watching this list, generating the Q&A and from time to time alerting this list to the appearance of new questions and answers, to allow knowledgeable people to do quality control. And/or inviting people to convert their answers on this list to the FAQ answers. This would relieve them from answering the same question over and over again and reduce the influx of questions from noobs (like myself J). I believe this would also strengthen the community and reduce the frustration of small relay operators and – who knows? – even lead to advancements in Tor design to make better use of them. I would appreciate that, but please learn some mailing list etiquette first. Otherwise, your contributions may be ignored by many people on the list. Some examples: * make sure each email adds something valuable to the conversation * structure your emails well: * learn how to bottom-post, even if your email client doesn't support it * learn how to quote others' emails to provide context to your response * try to write succinctly * keep the volume of your emails down: * write one response to a thread each day * search for similar threads before starting a new one * wait until an active thread is finished before starting a new one Caveat: I need someone (Tor project people) to create the Wiki on the site and let me admin it. Demonstrate you can do the things above, and I'll gladly set this up for you. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org _____

7 6

assign_to_cpuworker failed
by Felix 16 Jan '17

16 Jan '17

Hi diffusae > The only warning I have found close to it: > > "Jan 13 11:08:46.000 [warn] Your system clock just jumped 216 seconds > forward; assuming established circuits no longer work" > > That could be due to the IPv4 autodetection? Maybe I should explicitly > set the Address option in torrc? There was similar on 027 but more massive including * assign_to_cpuworker failed * Your system clock just jumped * stalling for seconds Which is resolved since 0289. 'Address' was key. https:// trac.torproject.org/projects/tor/ticket/20423#comment:27 -- imho - like always

2 1

(no subject)
by mario matko 15 Jan '17

15 Jan '17

mario

1 0

Entry relay still the same after months?weeks/
by je suis 15 Jan '17

15 Jan '17

Hello everyone And my apologies if this turns out to be a simple, obvious answer, but ever since two(?) upgrades back, my entry relay never changed. I manually deleted Browser/TorBrowser/Data/Tor/state and only then it changed. As of the last delete, it never changed, not with "New identity" or with "New Tor circuit for this site". Is this an intended behaviour? Thank you in advance, Vlad

2 2

torworld relays in entry and exit position
by nusenu 14 Jan '17

14 Jan '17

Hi torworld, thanks for joining the tor network with your relays! You are operating entry and exit relays without proper 'MyFamily' configuration, this can be dangerous for tor clients because they might choose you as entry _and_ exit relay, please help protect tor clients by properly specifying the MyFamily configuration in your torrc files. If you need any help please let us know. https://www.torworld.org/ https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… https://lists.riseup.net/www/arc/ornetradar/2016-10/msg00101.html kind regards, nusenu https://github.com/nusenu/ansible-relayor

1 1

Exit filtering Necto3 93.115.95.204
by Geoff Down 13 Jan '17

13 Jan '17

Would the operator of the above mentioned exit please remove OpenDNS 'Malicious URL' filtering. Thanks, GD (PS having a .onion contact address doesn't work, I think....) -- http://www.fastmail.com - Same, same, but different...

3 2

All I want for Chrismas is a bloody t-shirt
by I 11 Jan '17

11 Jan '17

9 19

Re: [tor-relays] How can we trust the guards?
by Rana 10 Jan '17

10 Jan '17

@Aeris I do not see how Sybil attacks relate to my question. The adversary will simply set up new nodes, without messing with attacking identities of existing ones. As to the rest of it, let us calculate. Assuming that the adversary wants to control 4000 nodes for 3 years, the 70d startup period is irrelevant and negligible. Assuming further that operating the relays will cost the adversary $20/month each, the total "investment" required would be 20x12x3x4000=less than $3million That’s $1million a year to control most of the Tor nodes., You call this "costly"? This amount is a joke, a trifle, petty cash for any US or Russian government agency. FIFTY times this amount is STILL petty cash, so in case you think $20/month is not enough to run a relay, make it $1000 a month. So I repeat - how is this prevented?

11 30

Re: [tor-relays] What's a "useful" relay?
by Rana 10 Jan '17

10 Jan '17

@Ivan >Some best practices definitely would be awesome to have about running on common (embedded) hardware. Clear notification like "your Commodore 64 is to slow to be a good relay" would also be useful. I agree about the need for guidelines but I disagree about the content of the guidelines that are needed. The data I see so far, including your report of a Pi with 7000 connections, is a clear indication that minimal hardware capabilities are NOT the guidelines that are needed (unless a relay with 7000 connections is still considered "harmful" or "useless"). My own Pi-based relay https://atlas.torproject.org/#details/707A9A3358E0D8653089AF32A097570A96400… has just reached 1300 connections; CPU utilization: practically zero; memory utilization: 14.5%. The increase from 500 to 1300 connections required memory utilization increase of just 2%, from 12.5% to 14.5%. Clearly, hardware of the $35 Pi has absolutely nothing to do with residential relays being useful or not, save the (recently reported here) anomaly of an operator who has symmetric BW of 160 mbps to the home. So guidelines on hardware are evidently not needed for "normal" residential ISP bandwidth: it has been amply demonstrated that even a dirt cheap Pi is not the bottleneck, no need to spend further effort on this until the REAL bottleneck is resolved: the network. To continue the story, the above relay of mine with 1300 connections has consensus BW rating of 38 (thirty eight). Why? Who knows. I get zero feedback on the reason for this. To further continue the story, my 2nd relay https://atlas.torproject.org/#details/31B8C4C4F1C78F923BD906769297B15A428C4… that currently has about the same Atlas-measured BW as the first relay (132 vs 153 KB/s) and is based on exactly the same hardware and software, is clinically dead with almost no connections and BW rating of 13. Why? Who knows. What is needed is a standardized feedback on WHY the relay has such a low rating. This could cause at least part of the operators to take care of the bottleneck (eg moving the relay to another location, or abandoning the home relay and replacing it with a hosted one). And if the home relay is indeed as harmful as some people here think, the recommendation should be issued to shut it down, instead of leaving it hanging there doing nothing or even harming Tor. Such feedback could significantly improve the quality and effectiveness of Tor. Based on the discussion here, the people who run Dirauths and bwauths know very well (or at least can easily find out) the reasons for relays getting low rating - why not automate the communication of the reasons to relay operators in clear, unequivocal and actionable terms? I get the feeling that people are trying to be "politically correct" here and it's a pity (although they DO respond fully and frankly when asked a direct question). Rana

2 3

Disparity between download and upload traffic
by Gage Parrott 10 Jan '17

10 Jan '17

Morning, everyone, I recently migrated my bridge relay over to a VM and everything seems to be working fine except for one oddity. I consistently see lines like this in tor's log file on the new machine: Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59 hours, with 43 circuits open. I've sent 1.78 GB and received 28.37 GB. Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59 hours, with 105 circuits open. I've sent 1.87 GB and received 29.24 GB. Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Notice the amount of data sent and received. Can anyone think of why there would be such a large discrepancy between the amount of traffic downloaded versus uploaded? This behavior persists after reboots, as well. I thought maybe it was downloading a ton of directory data, but is there really a GB's worth of directory data to download every six hours?? Also, the logs on my old machine (pre-migration, one line pasted below for reference) indicated that nearly the same amount of data was being sent as was being received. Any ideas on why would this have changed? Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12 hours, with 78 circuits open. I've sent 33.71 GB and received 33.47 GB. Any help is greatly appreciated. Thanks a bunch and merry Christmas! gp

2 3

Re: [tor-relays] Call for Tor Fallback Directories
by l3thal 09 Jan '17

09 Jan '17

please add my relays as fallback mirrors, thanks On Dec 4, 2016 5:45 AM, "teor" <teor2345(a)gmail.com> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Relay Operator, Your relay(s) can help tor clients find the tor network by becoming a fallback directory mirror.[0] These mirrors are hard-coded into tor's source code, like the directory authorities. We have 80 fallbacks, but we want 200 for the next release. Fallbacks need to have: - - the same IP address(es) and ports for the next 2 years, - - the same relay identity key for the next 2 years, - - good uptime (at least 95%), and - - good bandwidth and network connectivity (we estimate an extra 25GB per month). Please email me to add your relays that fit these criteria to the list. If you are BCC'd on this email, it looks like you have at least one relay that could become a fallback. You can also email me if you know your relay will be changing address or key, and I'll make sure we don't choose it. We are keeping the fallback lists from the last release[1][2]. So if you have emailed me before about becoming a fallback, there is no need to email again. But please let me know if your relay details have changed. (I did not BCC relay operators who are already on the fallback lists, unless their relay details changed.) In a week or two, I will run a script to select the hard-coded list for the release. If you're interested, here's some background to this request: The latest list[3] and log[4] of candidates was generated using the instructions in [5] from scripts/maint/updateFallbackDirs.py on my GitHub branch[6]. (This branch has some bug fixes compared to what's in master.) We're tracking this work in [7]. [0]: https://trac.torproject.org/projects/tor/wiki/doc/ FallbackDirectoryMirrors [1]: https://github.com/teor2345/tor/blob/fallbacks-029-v2/ scripts/maint/fallback.whitelist [2]: https://github.com/teor2345/tor/blob/fallbacks-029-v2/ scripts/maint/fallback.blacklist [3]: https://trac.torproject.org/projects/tor/attachment/ ticket/18828/potential_extra_fallbacks_2016-12-04 [4]: https://trac.torproject.org/projects/tor/attachment/ ticket/18828/potential_extra_fallbacks_2016-12-04.log [5]: https://trac.torproject.org/projects/tor/wiki/doc/ UpdatingFallbackDirectoryMirrors [6]: https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/ updateFallbackDirs.py [7]: https://trac.torproject.org/projects/tor/ticket/18828 T - -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org - ------------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYQ+laAAoJEEUMun+WjwlLXd8QAMVKWrGW+N5ij5/1k1AEDQpC qMK3C3stukeuHYqLEU3GnhJFU/CWMp+iThRNueC5I96MEpcioJDQaCDK6aGEvTY3 efPnYwOJcgE7v4up+JSFWUlO4HcF5Fu5cSVl710JjRiHuZAyLOQw0rWEMzfp0OQp sZLgijbtCUCcels7IS+bE89y4KKQvLu5lz+H7cPIcsx4TJ4QHd5LbWuvtNIHE2lW zA3LlrYsO4vtrFs/0kBWku1u7l1ZhD0Un/lwY7JWaxGmwm9C6kJDFwBFCGYRlakF VLfsoVSgcdjQPkZV9jeL0X+9Wn9L6zZ5JNhM5lhYYpGVD+Rl/apPfhxHI5aOTsGe WRcDjxvgUdMD//xnk2XTmnzKCNUNMyUKGSL8Y7Fadp7+dLLkWlovEp6iOnyAffh1 ZnrV7dhRgH3NcgACDpQ2rAqVzUnhdn1//bcD1MlXjObxvZD1Io1zp7CDQHnG6IaG ydc+3qoqUoII0JQFxrRCFi2cH/E8+3x0+7fC0g91irdGG+Pcosf7IFPJvFsdilCg rN4n6Ohmm1L3KQVWLG7TcvEAcjIeyMurhCvK042Q/X7HYenVS3wVxawd8dnb/rOl 0ItMUsXBKgLVcZXhzUTOB+pNaX8aFj1sJnCB2LRDT8s8a2+zESufNxjgGYZ3Nduk FziDqhHJs7MXyX0HPJPH =omox -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Running a relay with low transfer limits
by ike 09 Jan '17

09 Jan '17

Hi folks, Is there a generally accepted recommendation for how to set up a relay on a server with a fast connection but limited monthly transfers, say less than 100GB each way per month? Having done a bit of reading it seems daily limits are the way to go but I've found contradictory information regarding also limiting the bandwidth. Should I keep the relay accepting traffic (albeit slowly) for most of the day, allow a fast connection but for a very limited period every 24 hours or something in between. Thanks, Ike

8 9

Some thoughts from a tor bridge op
by a tor op 08 Jan '17

08 Jan '17

Hi I am a TOR bridge operator running a bridge with 8 Mbps advertised BW and having obfs4 installed. Been up a year or so on this install. I'll put a few misc thoughts out here, only been lurking on list earlier. I have been thinking a little about how useful this system is (MY bridge that is), in part since I haven't seen so much traffic lately. The latest few months I have seen some 1-4 (concurrent?) users according to Atlas whereas I had up to 10 during a year ago. There is also a count in tor log abut how many clients that have been seen in the latest hours etc. I then had a drop til nil due to not being updated when Lucky removed his Bridge Authority I think, or related to some other more or less related technical issue. What is a normal figure on this, anybody know? The thing is, in tor log it is reported that all is fine and that connectivity is ok. In Atlas these flags are reported: Fast Guard HSDir Running Stable V2Dir However, I have been thinking about a few other issues too though. One is, I noted that my provider gives this particular VPS a private IP address and traffic is NATed to the VPS according to info in the control panel. I do see a few GBs being pushed every other day so I guess things are kind of working, though. Is there something I may need to edit in config? Specifically the "OR Adresses" being mentioned on Atlas page contains a port that is not opened in local FW on server. Still it works and gets some client traffic(?) In torrc I some time earlier put in "ExtORPort auto" and also another port that is opened in FW using "ORPort". I also have the "ServerTransportListenAddr obfs4" with "0.0.0.0" and yet another port that is not being opened in FW, in the file. There are a few technicalities that might need some clearer explanation in manual/man/how-to I think. One thing I am thinking of is whether this private address and NATting issue makes the system not perform as I intend (although I do see some traffic as mentioned). Just a few thoughts. Any comments appreciated. A TOR bridge op

1 0

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

07 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 05 Jan '17

05 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