- tor-relays - lists.torproject.org

Tor Activities - CCCamp 2019
by gus 20 Aug '19

20 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 19 Aug '19

19 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 19 Aug '19

19 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 19 Aug '19

19 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 13 Aug '19

13 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 09 Aug '19

09 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 05 Aug '19

05 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 05 Aug '19

05 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 01 Aug '19

01 Aug '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 31 Jul '19

31 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 29 Jul '19

29 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 23 Jul '19

23 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 20 Jul '19

20 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 14 Jul '19

14 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