- tor-relays - lists.torproject.org

Bandwidth Measurement
by Marcobr 20 Feb '17

20 Feb '17

Hey everyone, as far as I know, the DAs running the bwauth scripts conduct hourly bandwidth measurements. Depending on the advertised bandwidth of the relay node, a smaller/bigger file gets transmitted on a custom 2-hop-circuit and the transmission time determines the actual bandwidth. Now, here is my problem: Assuming that my relay node advertised 50MB/s, and is currently at 98% load (49 MB/s). To conduct the measurement, the bwauth script will send a 8MB file over my relay, but since it can only serve another 1MB/s, how will the bwauth script determine that my advertised 50MB/s is correct?

3 2

Re: [tor-relays] tor-relays Digest, Vol 73, Issue 29
by contact＠charlieluna.com 20 Feb '17

20 Feb '17

On 2017-02-20 04:00, tor-relays-request(a)lists.torproject.org wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. large server farms (contact(a)charlieluna.com) > 2. Re: large server farms (teor) > 3. Re: large server farms (Duncan) > 4. Re: large server farms (I) > 5. Re: large server farms (niftybunny) > 6. Re: large server farms (anondroid) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 19 Feb 2017 16:44:25 -0800 > From: contact(a)charlieluna.com > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] large server farms > Message-ID: <457551c757ee4a355917f577d2f9a7ba(a)charlieluna.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > I'm highly interested in us creating a large server farm for Tor > services. The only question is how to get the coaxial cable ran from > the > server facility to each subscriber. The power requirements could be > handled by solar and wind systems and any water needs can be created by > means of water collection systems and solar heat collectors for hot > water. I think it's totally feasible. What do you guys think? > > Also, I'm very hardcore about taking back the internet for the people. > No more of this for-profit stuff where we get throttled and our freedom > of speech is abridged. Internet for the people is a means of freedom of > speech. Let's take it back. > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Feb 2017 11:47:46 +1100 > From: teor <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] large server farms > Message-ID: <E696CA8C-A1A6-4D14-8B3C-E901C81E7D55(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > >> On 20 Feb 2017, at 11:44, contact(a)charlieluna.com wrote: >> >> I'm highly interested in us creating a large server farm for Tor >> services. The only question is how to get the coaxial cable ran from >> the server facility to each subscriber > > Tor is a decentralised network, that's designed to be secure even if > users aren't directly connected to their network entry points. > > Can you tell us what you're trying to achieve for users by centralising > Tor services like this? > > (And what services you intend to provide?) > > 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 > ------------------------------------------------------------------------ > > > >

1 0

Is my relay alive?
by Ian Zimmerman 18 Feb '17

18 Feb '17

Hello, I started running a relay on my server [1] about 10 days ago. I checked the log to see about the self test and everything lloked OK. But even today there is only one file in the stats subdirectory: dirreq-stats. Is that normal? The "lifecycle" document tells me I should see normal traffic beginning around day 8. Is there a human-readable realtime (or close) list of relays? I see people posting here tables like the following, where do they come from? > 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 [1] 173.255.215.69 -- Please *no* private Cc: on mailing lists and newsgroups Personal signed mail: please _encrypt_ and sign Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

4 3

Proselytizing Tor at the General Strike
by Kenneth Freeman 18 Feb '17

18 Feb '17

On February 17, the day before Presidents Day, a general strike shall be held against any and all things Trump. If Boise is having an activists workshop, then there are plenty of tranches of fertile ground nationwide to plant Tor browsers, relays, and exit nodes. http://sfist.com/2017/02/02/nationwide_general_strike_gains_tra.php http://strike4democracy.com/ https://www.facebook.com/events/1756631744665376/ There's activism, and then there's activism. I would steer clear of actual OpSec unless you're in the right milieu. I have been told in introducing Tor that it can be difficult to conceptualize. I always tell people that your privacy is more configurable than you may realize, and that privacy horizons differ. Get down. Get encrypted.

1 1

Shutdown of TorLand1
by tor-admin＠torland.is 16 Feb '17

16 Feb '17

Hi all, after 5 years of operation I will shutdown TorLand1 (https://atlas.torproject.org/#details/E1E922A20AF608728824A620BADC6EFC8CB8C…) on February 17 2017. During the time of operation it pumped almost 6 PetaByte of exit traffic. Compared to the amount of traffic, the number of complains were quite low. Around 1-2 complains per week with a reduced exit policy. Two times I was contacted by LE via email. When I started the exit relay there were around 20-30 high capacity relays available. Today compass shows 180 95+ MBit/s exits. TorLand1 was operated and paid by me without an organization like torservers, nos onions, etc. I hope others will step up and run high capacity exits. The Tor network needs your help. I will continue to run a meek bridge. Regards, torland

10 9

Connectivity issues; disabling my relay
by Steven Chamberlain 16 Feb '17

16 Feb '17

Hello! My non-exit Tor relay "4pyro2eu3org0" in the United Kingdom is served by a consumer FTTC broadband line. It had a rare, unexplained outage on 2016-01-19 between 00:00 and 02:00 UTC. Two other lines with the same provider, terminating in the same local telephone exchange, were unaffected. When it came back, latency was different (lower) than before, to the first hop (the LNS in Birmingham) suggesting ATM traffic maybe taking a different (faster) route through BT's network *or* just my modem having resynced with different modulation. (Smokeping graph attached). But what concerns me, are intermittent bursts of packet loss (for about 3 seconds, happening every 10-60 seconds) which have been happening for more than 24 hours since. My ISP has checked with BT and assures me no maintenance work was scheduled that night; they see in their logs that my PPP session dropped at that time but believe no other customers at my local telephone exchange were affected. I consider that - whatever may be causing this - this kind of interruption to Tor relay traffic, could make timing attacks easier for an observer. So I'm shutting down my relay until this can be explained and fixed. At the very least, I should replace the BT Openreach-supplied VDSL modem (Huawei HG521) or its firmware with something I have more control over (and third parties have less control over...) Here's how the issue looks in mtr (at 1-second intervals); it affects all IP traffic. Maybe this is something benign, but I encourage other relay operators to be vigilant nonetheless. 1. 217.155.40.118 (Tor relay) ................................................................................... 2. 62.3.80.17 (LNS) .........................???......................???............???............... 3. x.x.x.x (test machine on same ISP) .........................???......................???............???............... and in reverse: 1. x.x.x.x (test machine on same ISP) ................................................................................... 2. 62.3.80.17 (LNS) ................................................................................... 3. 217.155.40.118 (Tor relay) .........................???......................???............???............... Regards, -- Steven Chamberlain steven(a)pyro.eu.org

3 4

[OrNetRadar] loskiq exit relays
by nusenu 14 Feb '17

14 Feb '17

Hi Amir, thanks for adding so many tor exit relays. You might want do consider rejecting port 25 in your ExitPolicy, that is the default: https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy Also please set the MyFamily in your torrc https://www.torproject.org/docs/tor-manual.html.en#MyFamily If you need help with that let us know. thanks, nusenu ornetradar(a)riseup.net: > 2017-02-11 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 1 | 09:34:02 | 13.94.150.167 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 1 | 13:20:08 | 13.74.174.90 | Microsoft Corpo | ie | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 1 | 10:30:29 | 13.81.62.91 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 1 | 15:10:13 | 40.69.73.77 | Microsoft Corpo | ie | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 1 | 20:00:54 | 40.118.98.190 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 1 | 11:37:42 | 13.73.158.253 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 0 | 0 | 11:56:32 | 104.47.155.162 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 0 | 17:03:54 | 13.69.10.96 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 0 | 15:36:37 | 52.164.227.83 | Microsoft Corpo | ie | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 1 | 09:49:38 | 104.46.34.192 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > 1 | 0 | 16:34:04 | 13.81.114.52 | Microsoft Corpo | nl | 8080 | 21 | Linux | 0.2.9.9 | loskiq | 1 > Fingerprints: > EBCFE46B8B756B44EC93BD833804C80341EB61CC,4896D07700198BE676543CC7F29A117C9DB8EE41,425C84600D0FD3781A553BD29D4E8782AB580120,4FAFBB649045A5C466ABBE6D702A55914DA2BEA7,05DBC69C4E392F83AF5C3F803913A3907E91DD6D,5245785C5CEBB51DD7CD9BBBB649AFE3FF5A85AD,1BFA55620CFC63B6ECE80877E282526E6F493903,7CCC661464AA0A954D2584B06D411175AFC91533,7E327AC4A36679C2A0A8F694B81CD182DB0E8560,0775CC3939EC0B749377EB53DFFEEA7E41F4CE82,5743EF596F776B20B1F0F551A9BF4EFCCE2E07EE >

1 1

Normal to lose stable/guard flags on relay reboot?
by Jivan Amara 13 Feb '17

13 Feb '17

Hi all, I recently rebooted a server hosting a relay (XOXXOX). Traffic plummeted to zero for five days and the relay lost all its flags except fast/running/valid. The server was down less than a minute. Is this normal?

4 5

My first relay is running
by Juan Guillermo Narvaez 13 Feb '17

13 Feb '17

Hello everyone! I'm start running my Tor relay today. Now what? =) -- J. Guillermo Narvaez @_aran0id

3 2

Reminder: If you are on 0.2.9.x, make sure you are running 0.2.9.9
by Nick Mathewson 12 Feb '17

12 Feb '17

Hi, awesome relay operators! About two weeks ago, we put out 0.2.9.9, to fix a significant problem in our build process that led to an easy remote crash attack: o Major bugfixes (security): - Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes -- and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha. If you are on some earlier version of 0.2.9.x, it would be really great if you could update your relay some time soon: I want to put out a fix for the underlying bug here, but I'm hesitant to do so while there are still 700 crashable relays on the network. Also if you are on 0.3.0.1-alpha, you should upgrade to 0.3.0.2-alpha or later, but there are only around 53 relays still on that version, so I'm freaking out less about that. best wishes and many thanks, -- Nick

14 22