- tor-relays - lists.torproject.org

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

14 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 11 Jan '17

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

11 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