- tor-relays - lists.torproject.org

3 questions
by niftybunny 29 Aug '19

29 Aug '19

Hi there, 1. anyone with any new news about the Darknet law in Germany or where you could ask for information? 2. Whats up with Torflow, still linked from Tor Atlas. As far as I can see it was last updated over 3,5 years ago? 3. So what happened to the new measurement? I can see a big spike https://metrics.torproject.org/bandwidth.html <https://metrics.torproject.org/bandwidth.html> and now its back to normal? Same with a lot of my relays, traffic doubled/tripled and now its the same or worse. niftybunny

2 2

Why is my Tor bridge relay not getting any traffic?
by Hikari 28 Aug '19

28 Aug '19

Hello everybody! I used to run a Tor bridge on Windows at home, where I have a 300/150 Mbps ISP. This Windows has memory leak and crashes after some hours, ad I believe that was making my bridge never get traffic. A few weeks ago I moved it to a Ubuntu server, also at home. I use uptimerobot.com to monitor if its port is reachable from outside and healthchecks.io to monitor if traffic entering from its local SOCKS port is reaching check.torproject.org. It's always up and reachable. But nyx reports it's rarely getting any traffic, and its bandwidth never surpasses 1KB/s. Its log heartbeat reports very little download and upload and always claims to has seen 0 unique clients. But how come, if my healthchecks.io monitor's curl call uses it every few minutes? metrics.torproject.org reports correct dates and uptime. Advertised Bandwidth is 58KB/s, way above what nyx reports. Flags are Fast, Running, V2Dir, Valid. What might be wrong? Or is it normal for a Tor bridge relay be this idle? This is my torrc removing identifiable data. |## Configuration file for a typical Tor user ## Last updated 9 October 2013 for Tor 0.2.5.2-alpha. ## (may or may not work for much older or much newer versions of Tor.) ## A handle for your relay, so people don't have to refer to it by key. Nickname MyNick ContactInfo mycontact ## Entry policies to allow/deny SOCKS requests based on IP address. SocksPort 9031 #SocksPort ::9031 #SocksPort 0.0.0.0:80 #SOCKSPolicy accept 192.168.* ## Send all messages of level 'notice' or higher to /var/log/tor/notices.log Log notice file /var/log/tor/notices.log ## Send every possible message to /var/log/tor/debug.log #Log debug file /var/log/tor/debug.log ## Use the system log instead of Tor's logfiles #Log notice syslog ## Uncomment this to start the process in the background... or use RunAsDaemon 1 ## The directory for keeping all the keys/etc. By default, we store ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. DataDirectory /var/lib/tor ## The port on which Tor will listen for local connections from Tor ## controller applications, as documented in control-spec.txt. ControlPort 9051 ## If you enable the controlport, be sure to enable one of these ## authentication methods, to prevent attackers from accessing it. CookieAuthentication 1 ################ This section is just for relays ##################### # ## See https://www.torproject.org/docs/tor-doc-relay for details. ## The IP address or full DNS name for incoming connections to your ## relay. Leave commented out and Tor will guess. Address hikari.mydomain.com ## Required: what port to advertise for incoming Tor connections. ORPort 80 ## Uncomment this to mirror directory information for others. Please do ## if you have enough bandwidth. DirPort 9030 # what port to advertise for directory connections ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy #ExtORPort 0.0.0.0:8000 ExtORPort 9041 ## Uncomment to return an arbitrary blob of html on your DirPort. Now you ## can explain what Tor is if anybody wonders why your IP address is ## contacting them. See contrib/tor-exit-notice.html in Tor's source ## distribution for a sample. #DirPortFrontPage /etc/tor/tor-exit-notice.html ExitPolicy reject *:* # don't run as an exit node BridgeRelay 1 # bridge PublishServerDescriptor 1 # published on bridge directory DB BridgeRecordUsageByCountry 1 # it's nice to see the country codes of users you are assisting #BandwidthRate 512000 #RelayBandwidthBurst 512000 #RelayBandwidthRate 512000 CellStatistics 1 PaddingStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ConnDirectionStatistics 1 HiddenServiceStatistics 1 ExtraInfoStatistics 1 #If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0) AvoidDiskWrites 0|

6 9

attack on my Finland exit/backup directory [9B31F1F1C1554F9FFB3455911F82E818EF7C7883]
by potlatch 28 Aug '19

28 Aug '19

I still haven't been able to rid myself of the Iranian servers revealed on the NYX connections page. I don't know their purpose but they slow the relay by about 85%. I have dropped them in the iptable input chain, restarted the VPS, but they show up after a day or two in spite. Today there were 121 of them with a large range of IPs. There have been as many as 1400 in a single day. None have identifiable hashed fingerprints. I've enclosed a couple attachments of my input table (partial) and the NYX connection page (also partial). Can anyone enlighten me regarding this situation? I will probably dump the exit relay if I can't fix this intrusion. Thanks people!! -potlatch Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Re: [tor-relays] Why is my Tor bridge relay not getting any traffic?
by Hikari 27 Aug '19

27 Aug '19

Thanks. It's been a few weeks I moved my relay to Ubuntu. I changed my Nickname and ContactInfo when I did that, so my fingerprint is new. Why is it on email bucket? Am I able to move it to bridges.torproject.org? On 27/08/2019 08:14 PM, Philipp Winter wrote: > On Tue, Aug 27, 2019 at 03:03:37PM -0300, Hikari wrote: >> Hello. Here's my fingerprint ------------ > > Your bridge is in the email bucket. It may not be requested as often as > over moat, but give it some time and you'll eventually see users. > > Cheers, > Philipp >

1 0

Improving throughput on weak CPU?
by Jochen 27 Aug '19

27 Aug '19

Hi there, I'm the operator of the following two exit nodes: https://metrics.torproject.org/rs.html#search/family:94C268630BEDCB64E7F888… My CPU is an Intel C2750 (8 cores total), which supports hardware accelerated AES yet a single process still maxes out at only ~150mbit/s. To get the most out of the machine and my single IPv4 address, I simply ran another relay which works fine, and now I'm averaging at around ~315mbit/s. Is there anything else I can tweak to improve throughput without having to order more IP addresses? I'm running Arch with stock 5.2.9 linux kernel. That being said, true multi threading would be much appreciated and would help people like me a lot :-) Regards, Jochen

4 4

AvoidDiskWrites
by [REDACTED] 25 Aug '19

25 Aug '19

Hi Torproject, i think about enabling AvoidDiskWrites 1 on all my relays and not only on my Pi because the prices for the VPS are anyway cheap as f*ck so i think saving the provider a few disk writes is a nice deal. In the manual it is described as: *AvoidDiskWrites* *0*|*1* If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0) ... which is not a very informative description on how it changes the behavior of Tor. I didnt found any more explanation about it. I would like to understand what Tor is NOT writing to disk anymore if set to 1 or what Tor IS writing to disk if set to 0 and if changing that have any effect for Tor users. As a relay operator i couldnt really see any difference enabled or not. Kind regards

3 2

tor relay ipv6
by armik900＠gmail.com 22 Aug '19

22 Aug '19

hi.in relay stopped working ipv6.address is correct all pings, including tor to the servers, but relay does not work.before that it worked perfectly 2 months.

6 12

Tor Relay - RelayBandwidthRate vs. RelayBandwidthBurst
by petrarca＠protonmail.ch 22 Aug '19

22 Aug '19

I'm struggling a bit with the two config options for RelayBandwidthRate and RelayBandwidthBurst - what I currently have in my torrc config file is: > ... > RelayBandwidthRate 8 Mbit > RelayBandwidthBurst 12 Mbit > ... My assumption was that on average the Relay would consume 8 Mbps max. but over a shorter period of time also up to 12 Mbps in case needed. What I see (historical monitor data at 10 s intervals for the past 6 months) is that the bandwidth usage never exceeds 8 Mbps. I can also see the consumption to be levelled out at 8 Mbps for minutes or hours so it looks like there would be a need for more bandwidth. My question: why can't I see the bandwidth usage going above 8 Mbps and making use of the allowed burst? Btw, I'm typically using the latest stable tor, currently the relay is on 0.4.0.5. Any comment welcome!

2 2

Very high CPU Load and low Traffic since Sunday
by Tim Niemeyer 20 Aug '19

20 Aug '19

Hello I've noticed a reduction in tor traffic about 50% since Sunday. The cpu load stayed almost same. The amount of TCP Sessions increased from ~34k to ~65k. Also the abuse rated about network scans got increased since Sunday. Does anyone knows what's there going on? My guess is that since Sunday anyone uses Tor for extended network scans, which results in a very high packet rate. Personally I've no problem with some network scans, but this is a bit annoying and I asked myself if this is still a scan or more a DOS. https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4… Kind regards Tim

7 7

Emerald Onion's new relays
by Christopher Sheats 19 Aug '19

19 Aug '19

Hello, Beginning this Wednesday, 2019-Apr-03, Emerald Onion will be starting 40 new uncapped and unfiltered exit relays using HardenedBSD in Seattle. We will turn on 10 new relays per day and be monitoring performance. In tandem, we will be publishing our updated edge routing and Tor relay configurations on our Github. We'll also publish an updated transparency report (spoiler: zero new requests). This work is part of our efforts to saturate our new unmetered 10Gbps transit link in the Westin data center. There we peer with the Seattle Internet Exchange with a separate 10Gbps connection. We'll be using our existing IP scopes: 2620:18C::/36 23.129.64.0/24 We are in the process of creating an RPKI ROA for our prefixes, and we are still rebuilding our DNS resolver (thanks nusenu for the feedback). These things will be completed before we turn on the new relays. If you donated to Emerald Onion (a 501(c)(3)) nonprofit), thank you! We'll be naming the relays accordingly. We will still accept new donations for relay naming rights-- email me directly for more information. Lastly, and If you're unaware, I spoke about our work at DEFCON 26: https://www.youtube.com/watch?v=cs6a1i4Owic Cheers, -- Christopher Sheats Executive Director for Emerald Onion Email: yawnbox(a)emeraldonion.org Office (& Signal): +1-206-739-3390 Website: https://emeraldonion.org/

12 20

Tor Activities - CCCamp 2019
by gus 19 Aug '19

19 Aug '19

Dear relay operators, The Chaos Communication Camp is an international, five-day open-air event for hackers and associated life-forms. It provides a relaxed atmosphere for free exchange of technical, social, and political ideas. == Tor Activities == * 2019/08/21 18:00 - Tor Relay Operator Meetup, about:freedom Village If you're a Tor user, operate a Tor relay, want to operate a Tor relay, or simply have questions, come and join us in this session with Q&A about the tor network and Tor Project. * 2019/08/22 12:30 - OONI: Measuring internet censorship around the world, about:freedom Village * 2019/08/22 13:30 - 14:55 - Tor Project: running Tor trainings with human rights defenders in Global South, about:freedom Village * 2019/08/23 14:00 - Updates from the Onion - The Road to Mobile Tor and Improved Censorship Circumvention, Room Curie == During all camp == Visit the Tor Project booth and the OONI booth in the about:freedom Village. https://blog.torproject.org/events/cccamp-germany

1 0

Attack on Tor exit and back-up directory server
by potlatch 18 Aug '19

18 Aug '19

Hello All, I commented and questioned earlier about significant slowing of one of my Finnish exit relays [1] and potential DoS attack. I took the server off line and did the best job I could hardening it. The host does not have DoS protection and uses Xen OpenVZ as his VPS manager. I was getting "nf_contract: table full, dropping packet." errors by the 1000s. That's fixed and I'm back on the Tor net now. One question remains: At any time I look there are 20-150 Iranian IP addresses trying to access the Tor server. Their IP range is from 5.113.x.x to 5.126.x.x. None have hashed fingerprints. Is it okay to let these guys go? Can they harm or slow Tor? Should I ban them? I'd like to learn from this. -potlatch Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

removal from the Fallback Directory list
by contact-tor-turing＠g0b.eu 18 Aug '19

18 Aug '19

hello, I managed until now the relay tor-turing - 8456DFA94161CDD99E480C2A2992C366C6564410 - ip 62.210.254.132 for four years and it was in the list of Fallback Directory. However he did not answer for 2 weeks, the support of my hosting provider told me that the motherboard is out of order and data are irrecoverable, so it should remove it from the list of Fallback Directory. thank you.

2 1

Fwd: Emerald Onion's new relays
by teor 18 Aug '19

18 Aug '19

Hi, We didn't clear the moderation queue last week, and this message was dropped from the queue. We'll make sure someone is looking at the queue every 1-3 days in future. T Begin forwarded message: >> On Mon, Aug 12, 2019 at 09:02:58PM +0200, lists(a)for-privacy.net wrote: >>> On 12.08.2019 02:46, Christopher Sheats wrote: >>> >>> It is discouraging to see so many small and large network operators >>> not using IPv6. Why is this such a problem? Tor Project, please >>> increase your #IPv6 awareness/outreach similar to how ARIN and the >>> other RIRs try very hard to do. >>> >> +1 >> >> Twitter :-( Wish you're on Mastodon, too. > > EO's Shawn Webb is on Mastodon: @lattera@bsd.network > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera(a)is.a.hacker.sx > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2

1 0

Removal from fallback directory mirror list
by Augusto Cezar Amaral 12 Aug '19

12 Aug '19

Hi folks, I'll need to shut down relay KrigHaBandolo (46791D156C9B6C255C2665D4D8393EC7DBAA7798). Can someone here help me with removing it from the fallback directory mirror list? Thanks

2 2

DoS attack on Tor exit relay
by potlatch 08 Aug '19

08 Aug '19

Hello Tor users, Help me with a problem please. I have a small exit/backup & directory VPS in Finland [1]. This last week the server (and Tor) have been overwhelmed with non-Tor IP addresses. This may be a small version of a DoS attack. I took the server down for a few days but when I restarted it the attack was there before Tor users. Eventually, the load caused kernal crash. I noticed this last week, that my Consensus Weight had dropped from 5500 to 68. Does anyone have an efficient way to defeat this ongoing attack? --potlatch [1] 9B31F1F1C1554F9FFB3455911F82E818EF7C7883 TorExitFinland Sent with [ProtonMail](https://protonmail.com) Secure Email.

7 10

10 Years Torservers.net: Death or Future?
by Moritz Bartl 08 Aug '19

08 Aug '19

tl;dr: torservers.net needs a new home! I started torservers.net after a random chat at a local bar some time early 2010. I wore a Tor shirt, and the guy next to me asked if that was "The Onion", the satire magazine. He became pretty excited about Tor after I told him what it was about, opened his wallet and gave me a 100€ bill "to put towards the network". Eventually it turned out that he was an Oracle software developer, so it's kind of funny to think about this as "one of the few good things Oracle has ever done". I thought about it for a bit, and then decided to take the money, which cemented the idea that I have had for quite some time: to get a more beefy machine to "properly" run a Tor exit, sharing the costs with others. Only a few days after I announced this idea on or-talk [1] in May 2010, some crazy Swede wired me another 1000€ (Thanks!). So, bad luck, I really had to do this now! I am still surprised at how successful the fundraising was. In fact, when we finally created a legal envelope of protection around me by starting the Zwiebelfreunde association in 2011, it was already clear that we needed to find others to do the same, instead of growing larger ourselves. The network was a lot different then, and some people tell me we had 80% of the overall exit capacity for quite some time after Olaf shut down his fast Blutmagie exit. So I went on a tour to inspire others. So, here we are, almost 10 years later, with 23 partner organizations in 15 countries. [2] After I got a "real job" in 2013 (that quickly grew into "more than full-time"), and at the same time the first grant money for torservers.net, we tried in many different ways to "recruit" others to "take over". Looking back, of course a lot of things happened and it was a crazy (and fun!) time, but long story short, until now nobody stepped up to take over the core role of a "coordinator" of activities. There are many many offers for help, and even more ideas of what torservers.net could do and be, but all people involved heavily at the beginning (Thanks!) don't have time to coordinate all the wonderful help, and do a proper handover. We tried a couple of times, only to spend a lot of time "training" a poor person to get them somewhat up to speed, but eventually everyone decided they had better things to do than to become frustrated at trying to walk blindly without much guidance. This is not an easy role to step into. If we take the May 2010 announcement as "launch date", the 10 years anniversary will be on May 10th, 2020. My dream would be to celebrate this with a fresh board at Zwiebelfreunde that has taken over the association, and another group that coordinates the international platform that torservers.net was meant to be(come). Of course we will not simply give away the domains and the legal entity and all our exit relays to just anyone. But, hm, yeah, truth is, probably almost anyone! ;-) For some years now, we've talked about the idea of a "relaunch". The most promising idea is to organize a proper Tor Relay Operators Retreat, maybe 50 people or so, with all the great people who have dedicated their lives to this project at some point, and all the great new folks who are as excited as all of us were back then about contributing to the Tor network. It would likely to be possible to convince Open Technology Fund or some other money source to sponsor travel and venue. I've always imagined this to happen in a nice "holiday" setting. At some point, I *will* go with a group of people to this fine venue [3], as an example of how this could look like. So far, I've tried to talk to individuals about it in smaller groups, and never announced it to the broader community in the way I do now. However, I still believe that this can only really be moved forward _in person_. I will do my best to ignore all mails you write to me or in this thread. Please write, coordinate, do everything that you think would be good to do to move this forward, but I don't really have the capacity to lead a good discussion. The only capacity I can offer is that we *need* someone to step up, and grab me at some event in meatspace. Ideally at that point that person is willing to have the A record pointed at some new place under their control, and we can begin the transition. Otherwise we will probably simply kill it for the 10 years anniversary, and finally make room for something new altogether. This is a call for help! Thanks. :-) Moritz P.S.: I will at some point soon post another mail about what I was up to the past years, and what I will be up to in the next few years. Don't worry, I'll still be around. [1] http://archives.seul.org/or/talk/May-2010/msg00058.html [2] https://torservers.net/partners.html [3] For a real Tor Relay Retreat, we would need something larger, but I think this gives you a pretty good idea of how I imagine it to look like: https://www.homeaway.co.uk/p868562

10 20

Running gigabit relay
by Mitar 07 Aug '19

07 Aug '19

Hi! I have Sonic Fiber which offers gigabit symmetric connection. I am thinking of using it for gigabit Tor relay, but I wonder what would be good hardware to use for something like that. Information I have found [1] is from 2010 so I wonder if there are any updates? Is there any simple small box I could use? Like Intel NUC? Information here [2] says that one can get 400 Mbps with AES-NI. And so with two processes limit per my public IP this would be around 800 Mbps then. Is this still a reasonable expectation? Do I have to care about the network card to serve gigabit (besides its being nominally gigabit)? What would be memory requirements for such a device? [1] https://www.mail-archive.com/or-talk@freehaven.net/msg14159.html [2] https://www.torservers.net/wiki/setup/server Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m

11 21

Configuring SQM on nodes
by Mitar 07 Aug '19

07 Aug '19

Hi! Has anyone tested how does configuring SQM on Tor nodes influence the quality of circuits over the node? Throughput, latency? So given that circuits have 3 hops in serial I would assume that any buffering/latency issues on nodes combine in a bad way. So using some smart queue management (SQM) might improve things? https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#why… So besides bandwidth measurements of nodes, should we also measure latency contributions by nodes? I think this is the whole idea behind the Bufferbloat movement, that it does not matter for user experience the final throughput if you have bad latency. That what most users perceive as "fast" is in fact good latency experience. Tor have notions of sustained and burst bandwidth, but this to me looks like just simplified QoS configurations. Shouldn't a better configuration be "do not increase latency by more than X"? Then if you hit the bandwidth limit, you are obviously increasing the latency more because some packets are not getting through. But it also captures the behavior better than "bursting is allowed up to Y". Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m

1 0

Tor server setup of keys
by potlatch 05 Aug '19

05 Aug '19

I have not installed a Tor relay since the gpg server change. I started a new relay today and found that the instructions for ubuntu Bionic did not work for me. Specifically, url https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E8… | gpg --import gave me an error message that --import is not an option of curl. Has anyone come across this and worked out the problem? -potlatch Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

New Fallbacks from June 2019
by teor 04 Aug '19

04 Aug '19

Dear Relay Operators, Thanks to everyone who opted-in their relays as fallback directory mirrors. We rebuilt the list of fallbacks in June 2019. [0] The new list will be released in Tor 0.4.1.4-alpha/rc. It was backported to all supported Tor releases. [1] The FallbackDir flags on Consensus Health [2] and Relay Search [3] might take a week or two to update. Don't worry if your relay missed out this time. It's still helping Tor users. And we will rebuild the fallback list again in 6-12 months time. We are tracking future fallback changes in this ticket [4]. To opt-in your relays, add a comment to the ticket [4], or reply to this thread. If you have multiple relays, you can opt-in as many as you like. (We picked up to 7 per operator this time, and we may pick more next time.) T [0]: See: https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc https://trac.torproject.org/projects/tor/ticket/28793 [1]: 0.2.9, 0.3.5, 0.4.0, and 0.4.1: See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… [2]: https://consensus-health.torproject.org/graphs.html Which uses stem's cached fallback list at: https://gitweb.torproject.org/stem.git/log/stem/cached_fallbacks.cfg [3]: For example, this relay is a new fallback, but its flag isn't shown yet: https://metrics.torproject.org/rs.html#details/1211AC1BBB8A1AF7CBA86BCE8689… [4]: https://trac.torproject.org/projects/tor/ticket/30972

2 2

ORPort // DirPort
by Fabio De Sicot 04 Aug '19

04 Aug '19

Hello everyone I have a problem I wasn't able to fix until now. Could you help me whit this? ------------------------ - when I start tor I receive this error: [...........] Aug 03 09:48:29.000 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. Aug 03 09:48:40.000 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. [...........] Aug 03 10:07:09.000 [warn] Your server () has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Aug 03 10:07:09.000 [warn] Your server () has not managed to confirm that its DirPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. - I verified, and ports 9051, 9001 and 9030 were not filtered # firewall-cmd --get-active-zones internal interfaces: eth0 # firewall-cmd --zone=internal --list-allinternal (active) target: default icmp-block-inversion: no interfaces: eth0 sources: ports: 9051/tcp 9051/udp 9001/tcp 9001/udp 9030/tcp 9030/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: - I checked my torrc file # cat /usr/local/etc/tor/torrcNickname xxxxxx ORPort 9001 <<<< ControlPort 9051 <<<< DirPort 9030 <<<< # # RunAsDaemon 0 ExitRelay 0 CookieAuthentication 1 ContactInfo xxxxxxx - I verified the internal ip # ifconfig eth0eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.8 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::1874:3d84:ac42:fa97 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:90:a2:b8 txqueuelen 1000 (Ethernet) RX packets 1118761 bytes 398404534 (379.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1095304 bytes 428598871 (408.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 - and I verified that on my router the port forwarding was active # Port Forwarding Name Port Range Protocol IP Address Enable TOR 9051 TCP&UDP 192.168.0.8 x ORPORT 9001 TCP&UDP 192.168.0.8 x DIRPORT 9030 TCP&UDP 192.168.0.8 x ------------------------ Thanks in advance Regatds -- Fabio De Sicot # https://fosstodon.org/@jolek78 <https://fosstodon.org/@jolek78>

2 1

Tor relay has low consensus weight
by Piers 04 Aug '19

04 Aug '19

Hi, i have been running a tor relay (link: https://metrics.torproject.org/rs.html#details/858BEC79D7355EC0631E98D47CF1…) on a raspberry pi 2 for 15 days, however i think there might be a problem with it. My consensus weight is only 43 and thus the relay doesn't get used much. Please advise if there is an issue -- Many thanks, -Piers

3 2

Unutilized bandwidth
by Alec Larsen 31 Jul '19

31 Jul '19

Hello, I've only recently joined this list, so I apologise in advance if this is not the appropriate place for my question. For the past month, I have been operating an exit node ( 89094DFA4158C7A1583EC3A332CDCBC74A28CC0E ) from UnitedIX in Chicago, IL, US. The server has a dedicated gigabit port, and I had hoped to be able to relay around 200 TB of traffic per month, but for some reason my advertised bandwidth has been hovering at just 12 MiB/s since the first few days. The server itself is an older Supermicro PfSense server with a Xeon E3-1270v3 at 3.5ghz and 32gb of RAM. It is currently running the latest stable release of FreeBSD (12.0p7) and Tor (0.4.0.5). As far as I can tell, the machine is mostly idle: * The Tor process is the most active, and I've yet to see it go above 5% CPU. * Memory usage is under 1.5gb. * Running `speedtest-cli` (even to different servers using the `--server` option) consistently gives 600mbps+ in both directions to most destinations. * There's nothing interesting in `dmesg` or the debug logs. Does anyone have suggestions for what the bottleneck here might be? I'm happy to share more details about my configuration if that would be helpful. Thank you in advance for any help that you are willing to provide! I think Tor provides a lot of value, and I would like to provide as much bandwidth as I can to the network. -- Alec

6 7

Cherryservers (formerly balticservers) account terminated for exit relay
by Chris Kerr 31 Jul '19

31 Jul '19

I just heard from the hosting provider cherryservers.com that they are terminating my account (after 2.5 years) where I run the exit relay "ostwaldripening" (46.166.162.53), because they no longer wish to host tor exit nodes. I tried to create an account on trac.torproject.org to edit the "GoodBadISPs" wiki page, but the spam blocking stopped me from doing so.

5 4

Re: [tor-relays] Windows Relay Setup
by William Pate 31 Jul '19

31 Jul '19

Hi! Well, I certainly expected far more snarky responses. :) Thank you for the links. I'll check them out and, if I get it to work, maybe write up a guide for others. Thank you! William ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, July 14, 2019 1:44 AM, Barton Bruce <barton.bruce(a)gmail.com> wrote: > > > William, > > On 7/11/2019 6:58 PM, William Pate wrote: > > > I'm interested in hosting a Windows-based relay, if anyone can point me to a good tutorial. I've tried the most common ones. > > > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > There used to be a VIDALIA (sp?) kit that could simply be downloaded and > run on a windows machine. I then worked for an ISP/CLEC and had lots of > bandwidth so ran Vidaalia on a 64 bit Windows 7 Ultimate machine on my > desk at work. > > I never did hear why something had changed at the tor project so that > stopped working, but do remember a rude snippy condescending reply from > someone on the mailing list so I lost interest. > > I did get the head Tor guy from the Central Square Cambridge office of > TOR to come speak at a local networking group's monthly meeting we held > at a MicroSlush faclity in Burlington, MA and it was well received by a > packed audience. I think he now has left TOR and works for some ISP. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus

4 3

exit operators: overall DNS failure rate above 5% - please check your DNS resolver
by nusenu 30 Jul '19

30 Jul '19

Dear Exit relay operators, first of all thanks for running exit relays! One of the crucial service that you provide in addition to forwarding TCP streams is DNS resolution for tor clients. Exit relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase significantly due to some major exit operators apparently having DNS issues and we would like to urge you to visit Arthur's "Tor Exit DNS Timeouts" page that shows you the DNS error rate for exit relays: https://arthuredelstein.net/exits/ (the page is usually updated once a day) Please consider checking your DNS if your exit relay consistently shows a non zero timeout rate - and make sure you run an up to date tor version. If you are an exit operator but have no (or no working) ContactInfo, please consider updating that field in your torrc so we can reach you if something is wrong with your relay. kind regards nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

11 15

Question about Bridges Bandwidth Authority
by s7r 28 Jul '19

28 Jul '19

Hello, I'd like to know more details about how exactly the bridge bandwidth authority works, and if we use the "weight" of each bridge for anything. For example, I have setup 5 obfs4 bridges, with the exact very same hardware resources and all on the same network speed of course. One of them gets used by clients (say 20-50 unique clients every 6 hours or so) while the rest of 4 are not used at all. This usage is not a concern for me, as its known bridges take time until they get used, depending on which bucket they have been assigned and etc. So I assume it's OK at this particular point in their lifetime to be unused by any client. But what I am curious about is, when I search them on RelaySearch, the used one has a measured bandwidth of over 2 MiB/s (and has the fast flag) while other 3 unused ones have bandwidths of between 50 and 60 KiB/s (these also have the fast flag) and there is one last one which is also not used and has a bandwidth of less than 10 KiB/s that does not have the fast flag. (Fast flag missing is also not my problem, I am just mentioning it as a side detail). Now I know for sure those values are not at all in according to the real environment. Each bridge should be at least capable of 3 MiB/s even if all 5 are used at the same time at their full speeds. Actually I have simulated this, it's not just theoretical. Is there anything related to usage, so that the bridge bandwidth authority only measures the used bridges? What could have cause such big discrepancy in my particular case, any ideas? Also, do we use the weight of each bridge in order to determine how much % probability it has to be served to a request in the bucket that is part of, or we don't use bridge weights for anything at all? Thanks!

3 4

Relay authority
by torjoy 26 Jul '19

26 Jul '19

Hi, this is my first post here. I'm running 3 bridges in brazil (maybe one of them becomes a middle-relay), so I want to know what we need here to have some bridge authority for example here in south america. Is too much different from a normal relay? I've already see the "authorithative flags" for torrc but dont made any changes. I think something more should be done and is not so easy. Best regards.

2 3

Re: [tor-relays] Call for setting up new obfs4 bridges
by dmz21＠ziggo.nl 22 Jul '19

22 Jul '19

> On July 19, 2019 at 1:44 PM Ben Riley <blades1000(a)gmail.com> wrote: > > > To follow up my previous email, I found the "Firewall" app and I've > manually opened 9051 & 8531 in that, and when I tested those via the online > port checking tools, they are now open. > > Restarted TOR (sudo systemctl restart tor) and the logs show it > bootstrapped to 100% and stated the ORPort 9051 is now reachable. > TOR did its bandwidth self-test.....done. > > Should that now be working ok? Yes, the logs look good. I think the ORPort indeed needs to be reachable for a bridge. You could try testing your own bridge using Tor Browser [1] or a Tails DVD [2]. Or wait a few hours (or weeks for the graphs) and look up your bridge on Tor Relay Search [3]. [1] https://www.torproject.org/download/ [2] https://tails.boum.org/ [3] https://metrics.torproject.org/rs.html# > Log now reads: > > Jul 19 21:31:43 ben-OptiPlex-755 Tor[8779]: Bootstrapped 10% (conn_done): > > Connected to a relay > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 14% (handshake): > > Handshaking with a relay > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 15% > > (handshake_done): Handshake with a relay done > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 75% > > (enough_dirinfo): Loaded enough directory info to build circuits > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 90% > > (ap_handshake_done): Handshake finished with a relay to build circuits > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 95% > > (circuit_create): Establishing a Tor circuit > > Jul 19 21:31:45 ben-OptiPlex-755 Tor[8779]: Guessed our IP address as > > 158.140.206.75 (source: 217.182.196.67). > > Jul 19 21:31:46 ben-OptiPlex-755 Tor[8779]: Bootstrapped 100% (done): Done > > Jul 19 21:31:46 ben-OptiPlex-755 Tor[8779]: Now checking whether ORPort > > 158.140.206.75:9051 is reachable... (this may take up to 20 minutes -- > > look for log messages indicating success) > > Jul 19 21:31:49 ben-OptiPlex-755 Tor[8779]: Self-testing indicates your > > ORPort is reachable from the outside. Excellent. Publishing server > > descriptor. > > Jul 19 21:32:14 ben-OptiPlex-755 Tor[8779]: New control connection opened. > > Jul 19 21:33:05 ben-OptiPlex-755 Tor[8779]: Your network connection speed > > appears to have changed. Resetting timeout to 60s after 18 timeouts and 129 > > buildtimes. > > Jul 19 21:33:07 ben-OptiPlex-755 Tor[8779]: Performing bandwidth > > self-test...done. > > > > On Fri, Jul 19, 2019 at 8:41 PM Ben Riley <blades1000(a)gmail.com> wrote: > > > Thanks for that. So I tried as you suggested and edited (gedit) the torrc > > file, replacing the obfs4 from 443 to 8531. > > I also added a port forward for that port on my router. > > Restarted TOR and the log file shows that it made a circuit (Bootstrapped > > 100%). > > I can now run nyx and see that TOR is trying to make connections. > > As per the log below, it seems that ORPort 9051 is unreachable (which is > > true according to a port checker) > > Though I've got the following ports forwarded on the router 9050, 9051, > > 443 & 8531 - 9001 is NOT forwarded though. > > > > Now the log says this: > > > >> Jul 19 19:53:58 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.969 [notice] > >> Tor 0.4.0.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, > >> Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.970 [notice] > >> Tor can't help you if you use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.990 [notice] > >> Read configuration file "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.990 [notice] > >> Read configuration file "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.997 [notice] > >> Based on detected system memory, MaxMemInQueues is set to 2862 MB. You can > >> override this by setting MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Configuration was valid > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Tor 0.4.0.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, > >> Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Tor can't help you if you use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Read configuration file "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Read configuration file "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.214 [notice] > >> Based on detected system memory, MaxMemInQueues is set to 2862 MB. You can > >> override this by setting MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening Socks listener on 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened Socks listener on 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening OR listener on 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened OR listener on 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening Extended OR listener on 127.0.0.1:0 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Extended OR listener listening on port 36399. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened Extended OR listener on 127.0.0.1:36399 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Tor 0.4.0.5 running on Linux > >> with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and > >> Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Tor can't help you if you > >> use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Read configuration file > >> "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Read configuration file > >> "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Based on detected system > >> memory, MaxMemInQueues is set to 2862 MB. You can override this by setting > >> MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening Socks listener on > >> 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened Socks listener on > >> 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening OR listener on > >> 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened OR listener on > >> 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening Extended OR listener > >> on 127.0.0.1:0 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Extended OR listener > >> listening on port 36399. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened Extended OR listener > >> on 127.0.0.1:36399 > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Parsing GEOIP IPv4 file > >> /usr/share/tor/geoip. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Parsing GEOIP IPv6 file > >> /usr/share/tor/geoip6. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Configured to measure > >> statistics. Look for the *-stats files that will first be written to the > >> data directory in 24 hours from now. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Your Tor server's identity > >> key fingerprint is 'MelbTORbridge 9F19251CEE17B1E05084898D164F0544CCB095DD' > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Your Tor bridge's hashed > >> identity key fingerprint is 'MelbTORbridge > >> E4AF099DA5946A6D6EA65DC55B517D3F9B12D0ED' > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Bootstrapped 0% (starting): > >> Starting > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Starting with guard context > >> "default" > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Signaled readiness to systemd > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Bootstrapped 5% (conn): > >> Connecting to a relay > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Registered server transport > >> 'obfs4' at '[::]:8531' > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opening Socks listener on > >> /run/tor/socks > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opened Socks listener on > >> /run/tor/socks > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opening Control listener on > >> /run/tor/control > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opened Control listener on > >> /run/tor/control > >> Jul 19 19:54:17 ben-OptiPlex-755 Tor[15449]: Bootstrapped 10% > >> (conn_done): Connected to a relay > >> Jul 19 19:54:17 ben-OptiPlex-755 Tor[15449]: Bootstrapped 14% > >> (handshake): Handshaking with a relay > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 15% > >> (handshake_done): Handshake with a relay done > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 20% > >> (onehop_create): Establishing an encrypted directory connection > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 25% > >> (requesting_status): Asking for networkstatus consensus > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 50% > >> (loading_descriptors): Loading relay descriptors > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Guessed our IP address as > >> 158.140.206.75 (source: 185.103.110.144). > >> Jul 19 19:54:20 ben-OptiPlex-755 Tor[15449]: I learned some more > >> directory information, but not enough to build a circuit: We have no recent > >> usable consensus. > >> Jul 19 19:54:21 ben-OptiPlex-755 Tor[15449]: I learned some more > >> directory information, but not enough to build a circuit: We're missing > >> descriptors for 1/2 of our primary entry guards (total microdescriptors: > >> 5382/6384). > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 75% > >> (enough_dirinfo): Loaded enough directory info to build circuits > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 90% > >> (ap_handshake_done): Handshake finished with a relay to build circuits > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 95% > >> (circuit_create): Establishing a Tor circuit > >> Jul 19 19:54:27 ben-OptiPlex-755 Tor[15449]: Bootstrapped 100% (done): > >> Done > >> Jul 19 19:54:27 ben-OptiPlex-755 Tor[15449]: Now checking whether ORPort > >> 158.140.206.75:9051 is reachable... (this may take up to 20 minutes -- > >> look for log messages indicating success) > >> Jul 19 19:55:35 ben-OptiPlex-755 dbus-daemon[3325]: [session uid=1000 > >> pid=3325] Activating service name='org.gnome.Calculator.SearchProvider' > >> requested by ':1.262' (uid=1000 pid=8482 comm="/usr/bin/gnome-shell " > >> label="unconfined") > >> Jul 19 19:55:36 ben-OptiPlex-755 dbus-daemon[3325]: [session uid=1000 > >> pid=3325] Successfully activated service > >> 'org.gnome.Calculator.SearchProvider' > >> Jul 19 19:55:42 ben-OptiPlex-755 nautilus[15604]: Could not get mtime for > >> 'file:///home/ben/.cache/tracker/meta.db': Error when getting information > >> for file “/home/ben/.cache/tracker/meta.db”: No such file or directory > >> Jul 19 19:55:43 ben-OptiPlex-755 bijiben-shell-s[15603]: Could not get > >> mtime for 'file:///home/ben/.cache/tracker/meta.db': Error when getting > >> information for file “/home/ben/.cache/tracker/meta.db”: No such file or > >> directory > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: Error opening > >> database: Could not open sqlite3 > >> database:'/home/ben/.cache/tracker/meta.db': unable to open database file > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: > >> tracker_sparql_query_exec_sql_cursor: assertion 'iface != NULL' failed > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: ___lambda11_: > >> assertion 'cursor != NULL' failed > >> Jul 19 19:55:49 ben-OptiPlex-755 Tor[15449]: New control connection > >> opened. > >> Jul 19 19:55:56 ben-OptiPlex-755 org.gnome.bijiben.SearchProvider[3325]: > >> Unable to load location /home/ben/.local/share/bijiben: Error opening > >> directory '/home/ben/.local/share/bijiben': No such file or directory > >> Jul 19 20:03:43 ben-OptiPlex-755 org.gnome.Shell.desktop[8482]: Window > >> manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a > >> timestamp of 0 for 0x6e00084 (torrc (/et) > >> Jul 19 20:14:38 ben-OptiPlex-755 Tor[15449]: Your server ( > >> 158.140.206.75:9051) has not managed to confirm that its ORPort is > >> reachable. Relays do not publish descriptors until their ORPort and DirPort > >> are reachable. Please check your firewalls, ports, address, /etc/hosts > >> file, etc. > >> > > > > > > On Fri, Jul 19, 2019 at 6:34 PM < > > dmz121(a)ziggo.nl> wrote: > > > >> > >> > On July 19, 2019 at 6:36 AM Ben Riley <blades1000(a)gmail.com> wrote: > >> > > >> > > >> > Hi, > >> > > >> > Thanks for the reply. Yes, I ran that command way back at the start. I'm > >> > assuming I don't have to run it every time the machine reboots or > >> updates? > >> > I ran it again this morning and it made no difference. > >> > > >> > Ah logs, you say that like I know where those are :P > >> > When I run sudo tail /var/log/tor/log - I get nothing. > >> > I found the Logs app and run that to get all the system logs - way too > >> much > >> > stuff and I couldn't move it to here, so I found this command (Google) > >> cat > >> > /var/log/syslog | grep tor -i and got the following (I think I've > >> included > >> > 2 set of attempts to boot up): > >> > > >> > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Starting with guard context > >> > > "default" > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Signaled readiness to > >> systemd > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bootstrapped 5% (conn): > >> > > Connecting to a relay > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Server managed proxy > >> > > encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: > >> > > permission denied) > >> > >> I ran (and keep running) into the same problem (but on Debian), even > >> after the fix suggested below. > >> Could you please try an unused port above 1024, like 8531? That resolved > >> this issue for me. > >> > >> hope this helps and kind regards. > >> > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Managed proxy at > >> > > '/usr/bin/obfs4proxy' failed the configuration protocol and will be > >> > > destroyed. > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: tor_assertion_failed_(): > >> Bug: > >> > > ../src/feature/client/transports.c:1836: > >> managed_proxy_stdout_callback: > >> > > Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on > >> Tor > >> > > 0.4.0.5 ) > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bug: Assertion > >> mp->conf_state > >> > > == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at > >> > > ../src/feature/client/transports.c:1836. Stack trace: (on Tor 0.4.0.5 > >> ) > >> > >> (removed rest of log) > >> > >> > > >> > > >> > > >> > On Fri, Jul 19, 2019 at 1:12 AM Philipp Winter <phw(a)torproject.org> > >> wrote: > >> > > >> > > On Thu, Jul 18, 2019 at 12:50:34PM +1000, Ben Riley wrote: > >> > > > Then I saw the above email about being a bridge and thought, fine, > >> I'll > >> > > > configure it to be a bridge and help out someone. > >> > > > Tried to do it via the docker/script method, but soon realised that > >> was > >> > > > outside my skill level (hey stop laughing! :P) > >> > > > >> > > Did you run into any specific issues? If you had troubles following > >> the > >> > > guide, I'm gonna blame the guide. > >> > > > >> > > > Setting ORPort to 443 as suggested. I forwarded that port on the > >> > > > router and then tested it, but it said it was closed. So I thought > >> my > >> > > > router was playing up. I checked a few other ports using online > >> tools > >> > > > and a few of them were closed. I forwarded a new another port to > >> some > >> > > > other software on another machine and that worked?! So I realised > >> the > >> > > > ports are open on the router but closed on the ubuntu machine. I've > >> > > > played around with all the settings, changed by torrc file to a > >> really > >> > > > basic one of: > >> > > > >> > > To run obfs4 on port 443, you will have to run the following command, > >> to > >> > > allow obfs4proxy to bind to port 443: > >> > > > >> > > sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy > >> > > > >> > > If you did that already, it would be helpful to see your logs. > >> > > > >> > > Cheers, > >> > > Philipp > >> > > _______________________________________________ > >> > > tor-relays mailing list > >> > > tor-relays(a)lists.torproject.org > >> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > > >> > _______________________________________________ > >> > tor-relays mailing list > >> > tor-relays(a)lists.torproject.org > >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > >

3 3

Limiting Tor Relay To Run On Google Cloud VPS
by Keifer Bly 20 Jul '19

20 Jul '19

Hi all, So a while back I was trying to run a tor relay via Google Cloud VPS but it was costing quite a bit. However, I was chatting with them, and I found out that as long as the relay generates a maximum of 4.9 GB per month and less than 2 million connections, it won't cost anything. I am wondering how to configure these limitations in tor? Thanks all. It's a small relay I know. --Keifer

4 4

Call for setting up new obfs4 bridges
by Philipp Winter 19 Jul '19

19 Jul '19

Hi everyone, BridgeDB is running low on obfs4 bridges and often fails to provide users with three bridges per request. Besides, we recently fixed a BridgeDB issue that could get an obfs4 bridge blocked because of its vanilla bridge descriptor: <https://bugs.torproject.org/28655> We therefore want to encourage volunteers to set up new obfs4 bridges to help censored users. Over the last few weeks, we have been improving our obfs4 setup guide which walks you through the process: <https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4…> The guide provides instructions for Debian, Ubuntu, CentOS, RHEL, OpenSUSE, FreeBSD, and OpenBSD. If you're running into any issues with the guide, please let us know! Finally, once you set up an obfs4 bridge, make sure that both your ORPort *and* your obfs4 port are reachable. Tor currently only tests the reachability of its ORPort. We set up a service that allows you to test the reachability of your obfs4 port: <https://bridges.torproject.org/scan/> Thanks for keeping the Tor network healthy by running relays and bridges! Thanks, Philipp

9 15

Windows Relay Setup
by William Pate 13 Jul '19

13 Jul '19

I'm interested in hosting a Windows-based relay, if anyone can point me to a good tutorial. I've tried the most common ones.

3 2

What fraction of Tor’s DNS traffic goes to Google and Cloudflare?
by nusenu 13 Jul '19

13 Jul '19

https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google… > 60.05% of the tor network’s exit capacity uses a resolver which is > located in the same autonomous system as the exit relay itself (that > includes localhost) which is recommended to minimize the path > between exit relay and its resolver. Lets aim to increase this > fraction to above 80%. > > If you are an exit operator and want to help reach this goal you can > use this list to verify you are not using Google or Cloudflare > resolvers. https://gist.github.com/nusenu/e6eec32679cc64ffe3e24d2b9367a931 > The Tor Relay Guide has instructions for setting up a > local DNS resolver. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

3 2

What rules for a fallback dir - the compiled-in fingerprint, a flag from the authorities or both?
by Toralf Förster 13 Jul '19

13 Jul '19

I do just wonder how a client decides whether/when fallback dir is to be used, especially when the *.inc file changed. -- Toralf PGP C4EACDDE 0076E94E

1 0

tor_bug_occured_(): This line should not have been reached
by [REDACTED] 08 Jul '19

08 Jul '19

Hey guys, my relay 79E683340B80676DCEB029E48FBD36BC66EBDA1E told me: Jul 06 15:22:34.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 150515 circuits rejected, 16 marked addresses. 0 connections closed. 104 single hop clients refused. Jul 06 16:23:25.000 [warn] tor_bug_occurred_(): Bug: ../src/core/or/channeltls.c:1111: channel_tls_handle_cell: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x562903c4faa6] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x562903c4b1c0] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x562903ad571a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x9a16a) [0x562903af916a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x562903ac318d] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x69ebe) [0x562903ac8ebe] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f469cdbf9ba] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f469cdc0537] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xb0) [0x562903aca290] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x562903ab80d5] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x562903ab530a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x562903ab4ec9] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f469c6a109b] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x562903ab4f1a] (on Tor 0.3.5.8 ) Jul 06 21:22:34.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00 hours, with 5113 circuits open. I've sent 2802.42 GB and received 2781.10 GB. Jul 06 21:22:34.000 [notice] Circuit handshake stats since last time: 13801/13801 TAP, 169020/169020 NTor. Its anyway a little bit strange because this is the only relay i have which never deleted his logfiles since i set it up and where i can not change the language of the operating system. I think its related to the host system but i never really thought about because it seems to work fine. Something i should do now?

2 1

Re: [tor-relays] Call for setting up new obfs4 bridges
by nottryingtobelame＠protonmail.com 08 Jul '19

08 Jul '19

Hello, I successfully ran an obfs4 bridge about a year ago that saw moderate traffic. After a few months, the traffic died off until I was consistently seeing 0 clients. I wiped the keys, got a new IP address, and started a new bridge. The 2nd bridge saw 0 clients, over several months. I finally wiped it again and started a 3rd bridge. Same thing, 0 clients for several months. My 4th bridge, which I took down last night, was up for just shy of 3 months with 0 clients. Before I took it down, I tested using https://bridges.torproject.org/scan/ and confirmed the ports were reachable. While I was not able to test the previous iterations, I setup the port forwarding for each of them for both the OR Port and the Ext OR Port that it randomly assigned. I won't be able to grab a new IP address this time, but I'm starting the bridge up again with new ID keys and new ports. Is it normal for bridges to see no traffic, and if they're not seeing any, should I keep them online?

2 1

Testing the accessibility of my obfs4 bridge
by nottryingtobelame＠protonmail.com 08 Jul '19

08 Jul '19

I plugged my bridgeline into Tor Browser on Windows, and connected successfully. I put it into Orbot on Android and also connected successfully. But when I put it into the new Tor Browser for Android, I am unable to connect. The logs from Tor Browser are pasted here: https://pastebin.com/cF5bwRH1. Any idea why one client would be failing to connect? Thanks in advance.

2 1

ExoneraTor results may be incomplete between April 25 and 30, 2019 and during other periods
by Karsten Loesing 08 Jul '19

08 Jul '19

Hello relay operators, it turns out that our exit scanner had an issue between April 25 and 29, 2019 and that ExoneraTor results may be incomplete during this time. Some context, taken from the ExoneraTor page: https://metrics.torproject.org/exonerator.html "The ExoneraTor service maintains a database of IP addresses that have been part of the Tor network. It answers the question whether there was a Tor relay running on a given IP address on a given date. ExoneraTor may store more than one IP address per relay if relays use a different IP address for exiting to the Internet than for registering in the Tor network, and it stores whether a relay permitted transit of Tor traffic to the open Internet at that time." Now, if somebody looks up their exit IP address during the time between April 25 and 29, 2019, their relay won't be listed in the results. It will still be included with the IP address that it used for registering at the directory authorities, but not with its exit IP address. I looked through the archive of exit lists and found similar downtimes of 18 hours or longer which would have the same effect: Gap of 19 hours between 2011-09-10T00:05:00 and 2011-09-10T19:28:46. Gap of 23 hours between 2011-12-21T01:21:19 and 2011-12-22T00:23:36. Gap of 111 hours between 2012-02-07T02:33:16 and 2012-02-11T18:07:47. Gap of 26 hours between 2013-03-07T15:16:50 and 2013-03-08T17:17:55. Gap of 156 hours between 2013-03-14T09:29:25 and 2013-03-20T22:03:41. Gap of 19 hours between 2015-10-09T14:13:37 and 2015-10-10T09:57:26. Gap of 18 hours between 2018-02-02T18:27:54 and 2018-02-03T13:06:09. Gap of 122 hours between 2019-04-25T13:13:19 and 2019-04-30T15:40:21. Gap of 21 hours between 2019-05-25T19:04:43 and 2019-05-26T16:09:23. We're working on adding a notice to ExoneraTor results in case a lookup falls into one of these periods, but that will take us some time. https://trac.torproject.org/projects/tor/ticket/31071 Sorry for any confusions caused by this! All the best, Karsten

1 0

obfs4 relay lost stable flag
by tor 30 Jun '19

30 Jun '19

Hi I've been running an obfs4 bridge for about a month. My hashed fingerprint is: E120A0492F789F5367EAD84C64F92EE279018F98 I recently lost the stable flag. Not sure why. Any thoughts? thanks matt

3 2

Tor Performance on Xen vs KVM
by Conrad Rockenhaus 30 Jun '19

30 Jun '19

Hello, I’m just curious on how people feel about relay performance on Tor nodes running on Xen vs KVM. I’ve noticed on Xen I have increased network performance and I do like the improved modular architecture of Xen vs KVM (right now I’m working on an experimental OpenStack w/ XCP-ng environment). I was wondering if any others on the list had experience running high performance Tor nodes on Xen and KVM and have a preference for one over the other… I’m just trying to compare and contrast here. Of course, I built a XCP-ng pool with a compute VM, then I have a regular KVM compute instance running under the Openstack framework. Thanks, Conrad Rockenhaus http://www.greyponyit.com/

1 0

BridgeDB currently up but non-functional?
by Rick Huebner 28 Jun '19

28 Jun '19

Hi, all. While skimming /r/tor on Reddit I saw a couple of posts saying they hadn't been able to get any usable bridges for several days, and thought I'd check into it. I downloaded & installed a fresh copy of the Windows TBB 8.5.1 and had it ask for bridges via Moat, and received 2 (not 3?) obfs4 bridge lines. Here's the Tor log from the "copy to clipboard" button that popped up on the TBB "connecting" dialog when it stalled at about 3/4th of the progress bar: 6/19/19, 10:46:16.735 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.735 [NOTICE] Switching to guard context "bridges" (was using "default") 6/19/19, 10:46:16.735 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.736 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:46:16.736 [NOTICE] Opening Socks listener on 127.0.0.1:9150 6/19/19, 10:46:16.736 [NOTICE] Opened Socks listener on 127.0.0.1:9150 6/19/19, 10:46:16.736 [NOTICE] Renaming old configuration file to "C:\Downloads\Tor Browser 8.5.1 - Copy\Browser\TorBrowser\Data\Tor\torrc.orig.1" 6/19/19, 10:46:23.608 [NOTICE] Bootstrapped 5%: Connecting to directory server 6/19/19, 10:46:23.611 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 6/19/19, 10:46:24.558 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection 6/19/19, 10:46:24.748 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus 6/19/19, 10:46:24.954 [NOTICE] new bridge descriptor 'eldritchworld' (fresh): $<BRIDGE 1 FINGERPRINT REDACTED>~eldritchworld at <BRIDGE 1 IP REDACTED> 6/19/19, 10:46:25.589 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:26.781 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus 6/19/19, 10:46:28.291 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. 6/19/19, 10:46:28.482 [NOTICE] Bootstrapped 40%: Loading authority key certs 6/19/19, 10:46:28.997 [NOTICE] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. 6/19/19, 10:46:28.997 [NOTICE] Bootstrapped 45%: Asking for relay descriptors for internal paths 6/19/19, 10:46:28.997 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6440, and can only build 0% of likely paths. (We have 100% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:28.997 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.275 [NOTICE] Bootstrapped 50%: Loading relay descriptors for internal paths 6/19/19, 10:46:29.463 [NOTICE] The current consensus contains exit nodes. Tor can build exit and internal paths. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.463 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.514 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.514 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:29.672 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.283 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Bootstrapped 57%: Loading relay descriptors 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.636 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.684 [NOTICE] Bootstrapped 64%: Loading relay descriptors 6/19/19, 10:46:30.684 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.733 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.873 [NOTICE] Bootstrapped 73%: Loading relay descriptors 6/19/19, 10:46:30.873 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.873 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.881 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.937 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:30.969 [NOTICE] Ignoring directory request, since no bridge nodes are available yet. 6/19/19, 10:46:44.618 [WARN] Proxy Client: unable to connect to <BRIDGE 2 IP REDACTED> ("general SOCKS server failure") It looks like bridge 1 (eldritchworld) gave me bad/incomplete relay info which prevented making circuits, and then Tor failed to connect to the fallback bridge 2 at all. Checking Relay Search, it shows that eldritchworld is a normal healthy-looking bridge that's been up for months with plenty of connections and data being transferred, so I don't know what's wrong there. So, since the Moat bridges didn't work, I went to the BridgeDB request web page to try that. Clicking the "Just give me bridges" button and doing the captcha returned "Uh oh, spaghettios! There currently aren't any bridges available... Perhaps you should try going back and choosing a different bridge type!". What, no vanilla bridges available at all? Seriously? (As a side note, cutesy errors are pretty annoying when things are failing. Just sayin'.) And as usual the Metrics page still shows about 1000 bridges, so something's badly broken. I know the new bridgedb release doesn't give out ORports if there's a secure PT offered, but last I checked the majority of bridges were just vanilla, so surely there must be enough to put some into whichever bridge pool ring my request was pulled from. I then tried asking for obfs4 bridges instead, and it did give me one (again, not 3?). With another fresh install of the TBB and entering that bridge line, the log shows: 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] Switching to guard context "bridges" (was using "default") 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. 6/19/19, 10:59:43.912 [NOTICE] Opening Socks listener on 127.0.0.1:9150 6/19/19, 10:59:43.912 [NOTICE] Opened Socks listener on 127.0.0.1:9150 6/19/19, 10:59:43.912 [NOTICE] Renaming old configuration file to "C:\Downloads\Tor Browser 8.5.1 - Copy\Browser\TorBrowser\Data\Tor\torrc.orig.1" 6/19/19, 10:59:50.761 [NOTICE] Bootstrapped 5%: Connecting to directory server 6/19/19, 10:59:50.762 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server 6/19/19, 11:00:11.767 [WARN] Proxy Client: unable to connect to <BRIDGE 3 IP> ("general SOCKS server failure") So this 3rd bridge also failed to connect at all. With the Moat and website requests both returning bad/dead bridges (if any), the last thing to try was the email request channel. I sent "request bridges" to bridges(a)torproject.org and it replied back "Here are your bridges: None, None, None". Well, okay then. Maybe if I try again later, which should give me different bridges to use? According to the bridgedb config file checked into the git repo, the rotation periods for the Moat and website bridge pool query positions are both 3 hours. So I waited 3.5 hours and tried those tests again on another fresh TBB install copy, and both Moat and the website returned back to me the exact same bridges as before, which then failed in the same ways as before. Maybe the running server isn't using the checked-in config settings? Waiting another 8 hours (11.5 total since the first try), Moat gave me the same first bridge but finally a different second bridge (still not 3), but that one also failed to connect at all with the same "general SOCKS server failure". The website still claims there are no vanilla bridges available at all, and gives me back the same single obfs4 choice as before, which still won't connect at all. I don't know if it's the link between the bridge authority and the bridgdb server, or the new bridgedb release that just came out or what, but something's badly broken and the bridgedb appears to be pretty much useless right now. My test environment is very standard, just Windows 10 Pro using only IPV4 from a normal US ISP (Frontier FIOS near Portland, OR) with no proxy, running a fresh copy of the current TBB build. The TBB works fine if I don't use a bridge or if I manually enter the bridge info for a private bridge relay I temporarily set up, and I have no other internet issues. Could someone else check if they see similar problems? Other people should supposedly get different bridgedb results pulled from the other bridge pool rings, but even if it's somehow only affecting one pool ring, that's like 20-25% of the bridgedb's users left with no viable results. Looking at the Metrics site I don't see any drop in current bridge user counts (actually it's in an uptrend, along with all tor user counts lately) but I'd assume most bridge users already have working bridge lines cached, so this would only affect new users or those whose old choices have gone down, but both of those categories will only grow with time.

2 5

An easy self-DoS and how to avoid it
by j4c4l4 28 Jun '19

28 Jun '19

Hi there, I have been operating a non-exit relay and a bridge for about one week now. I discovered by chance a quite silly self-DoS which could be triggered by using a NIDS (Network Intrusion Detection System) on relays. I don't know if it is known, but I thought it was worth reporting it here. In many Linux distributions, several NIDSs come with a default policy that blocks all the traffic from offending IPs after they have reached a threshold score. The offending IPs are normally put into a separate firewall chain/table that DROPs all the traffic originating from them, and then re-enabled after a period that could vary between 30 minutes and a few hours (again, depending on the config). Now, this could be potentially used to periodically shut down relays. In fact, an attacker could perform something as simple as an ssh login scan *through tor*, which is among the "attacks" monitored by most of the NIDS out there. But since the login attempts appear to originate from the tor exit relay, this effectively flags *the exit* as an "offending" host, and triggers the corresponding firewall rule (which is normally a blind "DROP", to save on rule processing). Once an exit node is flagged as "offending" and put in the firewall rule, any traffic between the relay and the exit node is effectively forbidden, until the firewall rule is removed or the tables flushed. If performed on a large scale, this can potentially shut down all the relays which run a NIDS with such policy on ssh logins. The same is true for other simulated attacks on other protocols (but ssh monitoring and blind DROPs are so much common to be the ones of most concern, maybe). I don't know how many relays run a NIDS (I suspect several do, actually), but it would be better to be aware of this potential self-DoS attack. The easy solution (apart from not using any IDS on relays) is to make sure that all the incoming traffic to the ORPort is always accepted, e.g. introducing an ad-hoc firewall first rule that accepts all TCP stuff from the ORPort, before processing NIDS-managed rules. Sorry if this was known already, but I couldn't find anything related by looking at the recent topics in the ML archives, and I thought it coud be useful to share. Regards

1 0

Best practice for tor-exit node when I switch internet providers?
by Chris Dagdigian 28 Jun '19

28 Jun '19

Hello, I've been running a tor exit node in the US since 2014 when I paid way too much for a comcast business internet circuit that came with static IPs and a TOS that allowed me to run servers at home. It looks like I'm going to switch providers in a month or so as there is a fiber service I can get with symmetric bandwidth, the static IP count I want and theoretically also a TOS that is also amenable to server hosting. What is the best practice if I want to keep my tor exit going but switch upstream carriers and IP addresses? I'm guessing this is going to trip a bunch of tor monitoring alerts if I just bring the server up at a new IP address. Should I change the nickname? Totally wipe and reinstall tor itself? The goal is to bring back the same exit node but not set off any alarms when the exit node with the same IP for many years suddenly shows up with a new address. -Chris

2 1

torrelays have no bandwith
by TorGate 28 Jun '19

28 Jun '19

Hi to all, i have issues with my 3 relays, there is no bandwith ?! i have not changed the config only updatet the tor software. In nyx can i see there are smal bandwith connections 1-100 kbs. All 3 relays have a 5mbit up/down connection. https://metrics.torproject.org/rs.html#search/torgate

3 3

Interesting Reddit Post for Tor Relay Operators on Verizon FiOS (Verizon blocks Verizon.com on Tor Relay IP Addresses Including Non-Exit Relays)
by neel＠neelc.org 26 Jun '19

26 Jun '19

Hi tor-relays@ mailing list, If you are running Tor relays on FiOS, or run Tor relays and are considering joining FiOS, here's an interesting Reddit Post: Title: Verizon blocks Verizon.com on Tor Relay IP Addresses (Including Non-Exit Relays) URL: https://www.reddit.com/r/privacy/comments/c5whh5/verizon_blocks_verizoncom_… -Neel Chauhan === https://www.neelc.org/

1 0

TCP SACK PANIC type kernel vulnerabilities: logging some packets
by tor＠t-3.net 25 Jun '19

25 Jun '19

As of last week there wasn't a new kernel out for our relay's distro, so I implemented an IPTables-based mitigation in our relay as such: -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j LOG --log-prefix "TCP_SACK_PANIC: " -A INPUT -p tcp --tcp-flags SYN SYN -m tcpmss --mss 1:500 -j DROP Over the weekend we logged hits to this rule. I checked a few of the source hosts, and they were not relays at least as they are listed in https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 . I'll pull the rule out once the kernel is patched, but yeah. Things that make you go hmm.

2 1

Re: [tor-relays] Tor memory leak (0.3.5.7)?
by starlight.2018q2＠binnacle.cx 25 Jun '19

25 Jun '19

Hi, No leaks. The VM has 1GB, very light for moderate busy relay. Should be 4GB, perhaps 3DB would do. Settings should include: AvoidDiskWrites 1 DisableAllSwap 1 MaxMemInQueues 1024MB # perhaps 1536MB My relays run about 800MB to 1.2GB. A nice way to view memory usage is with egrep '^Vm' /proc/$(cat /var/run/tor.pid)/status which might show something like VmPeak: 871696 kB VmSize: 710152 kB VmLck: 710148 kB VmHWM: 810872 kB VmRSS: 649328 kB VmData: 492052 kB VmStk: 93 kB VmExe: 4704 kB VmLib: 104724 kB VmPTE: 1044 kB Notice that current VmSize usage is less than VmPeak, indicating that memory was release by glibc malloc. Tor consumes substantial skbuf memory in the kernel, which accounts for some of the difference in reported size for VmRSS and VmSize and total memory consumption.

3 2

Build problem
by dns1983＠riseup.net 25 Jun '19

25 Jun '19

Hello, I'm trying to build tor for from source on a x86 Debian stretch machine. I first installed all dependencies, but when I launch the "./configure" command I see the following error: configure: WARNING: Unable to find liblzma. configure: WARNING: Unable to find libzstd I installed, among the others liblzma-dev, lzma, libzstd-dev and zstd. I'm working through ssh. What I'm doing wrong? Could It be caused by a wrong environment variables settings? Cheers Gigi

2 2

obfs4proxy installation from deb.torproject.org says Release file expired
by s7r 25 Jun '19

25 Jun '19

Hello, Trying to spin some new obfs4bridges. I am using: deb.torproject.org/torproject.org obfs4proxy main in /etc/apt/sources.list -- I hope this is correct. I get this: E: Release file for https://deb.torproject.org/torproject.org/dists/obfs4proxy/InRelease is expired (invalid since 1d 15h 7min 11s). Updates for this repository will not be applied. Just recently saw Yawning's release notification, is it somehow related? Thanks.

2 1