- tor-relays - lists.torproject.org

Liberation Day article on running a relay
by Imre Jonk 05 May '20

05 May '20

Hi all, Today the Netherlands celebrates the 75th anniversary of our liberation from Nazi Germany by allied troops in 1945. Normally there would be festivities around the country with presence from organizations like Bits of Freedom and Amnesty, but those are cancelled because of the ongoing pandemic. That means that we celebrate from home this year, which leaves me with time to finish this article: https://www.imrejonk.nl/running-a-tor-relay/ The goal of the article is to answer frequently asked questions that aspiring relay operators might have, while linking to authoritative documentation of the Tor Project as well as this list for further information. Hope you enjoy reading it, feedback is welcome :) Imre

1 0

Feature request to aide bridge operators
by nottryingtobelame＠protonmail.com 05 May '20

05 May '20

I brought up a new bridge and thought everything was fine according to the logs (OR port accessible, check, server descriptor published, check, etc.). I didn't see any activity on it after awhile, so I tried to test it and was unable to connect. Turns out, I forgot to open the randomized server transport port. I think it would be really nice if there was a log entry confirming the OBFS4 port is open and accessible. Currently the only entry you get related to this is "[notice] Registered server transport 'obfs4' at '[::]:35375'". Wondering how the community feels about this. Thanks.

2 1

Again: abuse email for non-exit relay (masergy)
by lists＠for-privacy.net 04 May '20

04 May '20

Hi, got multiple abuse in the last 2 weeks. 2 relays with 2 IP run on the server. Someone is always hammering my OR port on one IP. (37.157.255.118:9002) https://metrics.torproject.org/rs.html#details/BD2A34ADE4E603A272FAAD23AEF3… https://metrics.torproject.org/rs.html#details/8EE44717FA55705C12086F3ECD1F… What can I do? Found that in the archive: https://lists.torproject.org/pipermail/tor-relays/2017-September/013030.html the 5th complaint: ############################################################################################################## To Whom it May Concern, You have a system on your network that is actively scanning and/or attacking external sites on the Internet. This can come from many sources and because it is often difficult to detect this activity, we are sending this E-mail in an attempt to help you solve the problem. We have detected your system with an IP of, 37.157.255.118, scanning a client we monitor. This was not a short attack but a prolonged scan and/or probe that was designed to find and intrude into the target network. This may be someone on your network who is actively trying to hack others. This person may be a legitimate user on your network or it may be that this system has been compromised and is being used by someone to hack others. It is also likely that the system is running automated tools that have been installed to perform these actions without any human intervention. Below is the information about the attack. Keep in mind that the source IP of our client has been sanitized for anonymity. Date: 04/30/2020 Time: 11:05:37 Time Zone: America/Chicago Source(s): 37.157.255.118 Type of Attack/Scan: Generic Hosts: 10.10.10.182 Log: 37.157.255.118:9002 > 10.10.10.182:24562 Possible Cause: Thank you for your attention to this matter, Masergy email: esp(a)masergy.com -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

6 8

(Без темы)
by Станислав 04 May '20

04 May '20

2 2

Recommended router for 200+ Mb/s relay
by Secure Node 03 May '20

03 May '20

Hi, I'm hosting 150+ Mb/s relay for a while now: https://metrics.torproject.org/rs.html#details/333C874B532B3EA7E1A40980B765… I'm looking for new router for good price which can handle more connections and traffic ;-) Can you recommend any specific models? Should I avoid some products lines or companies? It's possible to get something usable in range ~£100 for used one?

6 6

(no subject)
by Станислав 02 May '20

02 May '20

2 4

Debian-tor Vs User
by Kathi Hilton 26 Apr '20

26 Apr '20

Switch from root to user = su usrname >Password. The problems start when I try and su to debian-tor. First I get a query for a password which it doesn't have. So I make a pass for debian-tor and enter it when I su to debian-tor. I enter whoami and the response is: user and not debian-tor. With or without a password it doesn't work. Secondly, if I su debia-tor > passwrd - sudo -u debian-tor nyx it produces a page and a half of pure gibberish. Sudo -i to root and enter nyx, it operates perfectly; and yes I understand I shouldn't run nyx as root. How do I become debian-tor so I can operate my bridge correctly? Adriann -- It can't be, so therefore it isn't - stanton Friedman

8 7

(no subject)
by Станислав 26 Apr '20

26 Apr '20

1 0

Why does my relay often appears offline in Metrics and should I be worry?
by Clément Février 19 Apr '20

19 Apr '20

Hello, I often check my relay trough Metrics, but it often appears as offline after some time, from couple of hours to few days. I think it has this behavior since December 20. However, my relay seems to run normally. I have the usual number of connections when I check in Nyx. I don't see anything in the log. But, in Nyx, I don't see the flags that I see when it appears as online in Metrics. What I do is to restart the service, but I'm not sure if it's what I'm suppose to do. Is there an explanation or can you help me to investigate this issue? FYI, the tor, version 0.4.2.7, is running on a Ubuntu server 18.04 within a LXD container. My relay fingerprint is 33D88F331408141F2A2CC563239E54E48F7A211B https://metrics.torproject.org/rs.html#details/33D88F331408141F2A2CC563239E… Thanks, Clèm

4 5

(Без темы)
by Станислав 18 Apr '20

18 Apr '20

2 1

Got my first abuse
by lists＠for-privacy.net 18 Apr '20

18 Apr '20

Hi, my Family¹ has had an exit for 2 weeks and today the first abuse mail has arrived. First of all, thanks for the templates: https://www.torservers.net/wiki/abuse/templates https://trac.torproject.org/projects/tor/wiki/doc/TorAbuseTemplates I linked these two from the Tor-project: - Common Boilerplate (Tor Intro) - SSH Bruteforce Attempts and wrote the following myself: -------------------------------------- Another good option that we use ourselves is: fail2ban And report to blacklists, which can then be loaded into the router firewalls: https://www.abuseipdb.com/user/33280 Hope this helps! -------------------------------------- I actually wanted to add that the SSH login attempts can be limited. (3-6) Because the logs from the abuse mail showed 100 attempts pro IP. ;-) _Are such notes useful or do such instructions cause even more problems?_ ¹https://metrics.torproject.org/rs.html#search/TorOrDie4privacyNET -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

12 20

Help with torrc for Bridge
by ylms 18 Apr '20

18 Apr '20

Hello all I just set up a bridge and want to make sure I didn't forget anything. //the torrc I use Nickname FancyNick ContactInfo see https://example.com/torcontact/ ControlPort 9051 ORPort 443 SocksPort 0 BridgeRelay 1 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:80 ExtORPort auto CookieAuthentication 1 ExitPolicy reject *:* ExitPolicy reject6 *:* ClientUseIPv6 1 #%include /etc/tor/torrc_family //End of torrc For the family, is this setting needed for a Bridge? Should it be set? Thanks for any advice yl

2 4

Re: [tor-relays] 100% CPU at random rate
by scullcactus 17 Apr '20

17 Apr '20

Thanks Gisle and petrarca for confirming that. I thought this is because of my messed-up OS only. I linked this thread to the trac's ticket #33554 to for more info on that. On 17.04.2020 21:27, Gisle Vanem wrote: >> My problem is, and long time has been, the following. Every 30-40-60-120 >> minutes (it varies) I suddenly see CPU consumption jumps to 100% because >> of tor process, so I need to stop/start it to settle things down. Also, >> when I start Tor after a period of inactivity, say, a few hours or >> night, I cannot start it reliably for the first time, ever. It goes up >> to "Bootstrapped 95% (circuit_create): Establishing a Tor circuit" log >> message and... 100% CPU. After the second start, I get 100% CPU with >> 50/50 probability, and after the 3rd, it finally is OK, most of the >> time. Then, this 30-40-60-120 minutes cycle begins... It happens with >> this "Bootstrapped 95% ..." message or a bit before that. > > I've seen the same and patched like this: > > --- a/lib/thread/compat_winthreads.c 2020-01-24 21:59:07 > +++ b/lib/thread/compat_winthreads.c 2020-04-09 08:55:04 > @@ -170,6 +170,8 @@ > do { > DWORD res; > res = WaitForSingleObject(cond->event, ms); > + > + SleepEx(1, TRUE); > EnterCriticalSection(&cond->lock); > if (cond->n_to_wake && > cond->generation != generation_at_start) { > > ------------- > > That always did the trick. > > I reported it here: > https://trac.torproject.org/projects/tor/ticket/33411 > > --gv

1 0

100% CPU at random rate
by scullcactus 17 Apr '20

17 Apr '20

Hello list. This is my 1st message here, and I'm not a pro, so please excuse me if I do something wrong. I run a relay for several years now. This is my personal notebook so I only start Tor when I power it up. I set it up for 2 things: to be a node (non-exit) and to serve me as a SOCKS proxy for accessing some sites I have here blocked. My problem is, and long time has been, the following. Every 30-40-60-120 minutes (it varies) I suddenly see CPU consumption jumps to 100% because of tor process, so I need to stop/start it to settle things down. Also, when I start Tor after a period of inactivity, say, a few hours or night, I cannot start it reliably for the first time, ever. It goes up to "Bootstrapped 95% (circuit_create): Establishing a Tor circuit" log message and... 100% CPU. After the second start, I get 100% CPU with 50/50 probability, and after the 3rd, it finally is OK, most of the time. Then, this 30-40-60-120 minutes cycle begins... It happens with this "Bootstrapped 95% ..." message or a bit before that. I experienced it with many 0.3.x, 0.4.1.x versions, now with 0.4.2.x versions also. I tried not to restart tor process when it eats my CPU for several minutes but it doesn't stop, so I have to stop/start it manually. I see nothing bad in the log at its NOTICE level. My setup now is: Windows 8 Tor is 0.4.2.6 Fingerprint BF4591C167FF01B8AAE2749CD9D04913BD6743C4 I run Tor as a Service (--service install cli option; start manually) My notebook is decently powerful and so is my network connection My torrc is basically like this: SOCKSPort [port] SOCKSPolicy accept private:*,reject *:* Log notice file C:\tor-0.4.2.6\var\notice.log DataDirectory C:\tor-0.4.2.6\var ControlPort [port] HashedControlPassword [cencored] MaxMemInQueues 1 Gb Address [my real ip] Nickname skullcactus ORPort 59001 NoListen ORPort 192.168.0.84:9001 NoAdvertise DirPort 59030 NoListen DirPort 192.168.0.84:9030 NoAdvertise RelayBandwidthRate 3 MBytes RelayBandwidthBurst 6 MBytes ExitRelay 0 GeoIPFile C:\tor-0.4.2.6\Data\Tor\geoip GeoIPv6File C:\tor-0.4.2.6\Data\Tor\geoip6 ExcludeExitNodes [some exclusions] StrictNodes 1 TrackHostExits [some hosts] TrackHostExitsExpire 600 HeartbeatPeriod 1 hours Really, I want to keep my node working but it gets on my nerves :-) . Can you please help me track the problem down?

3 2

Wrong IP geolocation
by Mario Costa 17 Apr '20

17 Apr '20

One of my relays is reporting a wrong country and AS Name/Number on the Tor Metrics page. I suspect that the other relays displayed filtering by AS Name have the same problem since all of them belong to the same 255.255.0.0 subnet. I know precisely where my relay’s data center is, and it’s not the reported country. How can I report the correct location? Browsing Tor’s source it looks to me that it downloads a database from https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country.mmdb.gz <https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country.mmdb.gz> but the link is not working, and it seems that they now require an account in order to access the data. I don’t know if the Metrics page is using the same database. -m

3 2

Low observed bandwith
by Mario Costa 16 Apr '20

16 Apr '20

Hi list, I’m running a guard relay from my home connection on a Raspberry Pi 4. My internet connection is 1000/100 Mbps, and I thought I’d allocate half of the upload bandwidth for the relay. Then I set RelayBandwidthRate to 10 MB/s, because I thought that Tor would upload 5 MB/s and download 5 MB/s. However, the maximum observed bandwidth was always about 6 MB/s. I’d like to know what could cause this low observed bandwidth. I don’t think it’s the Raspberry Pi, because CPU usage is always low and it has a Gigabit connection to the router. The router itself easily reaches Gigabit speeds, so 10 MB/s should be a breeze. Could it be the number of connections? nyx indicates that the connections are always about 4000. If this is the case, how can I know if the connections bottleneck is the router or the Raspberry Pi? Additionally, I’d like to ask for a rule of thumb for setting the RelayBandwithBurst. I set it to 20 MB/s because I’m ok with the relay using the whole upload bandwidth (about 10 MB/s, or 100 Mbps) for short periods of time, but as I already explained I’m never seeing such speeds. For reference my relay’s fingerprint is F942EE73F1B8E39125F617FA85E80E4C9E540A2E. -m

4 5

Multiple obsf4 Bridge Relays on macOS
by Wilton Gorske 15 Apr '20

15 Apr '20

Hi all, Firstly, I hope you're taking care and staying safe (against pandemics and surveillance, especially considering how the latter is taking advantage of the former). Secondly, and mainly, I am working on setting up ten obsf4 bridge relays on macOS and keep running into port issues, so I'm hoping to get some general advice and guidance about how to set this up in the absence of updated macOS tutorials online. These bridge relays are going to run on one macOS server. Knowing that they can each have their own dedicated IP address, could someone advise how to best set up these multiple obsf4 bridge instances so each can be run (tor -f /usr/local/etc/tor/torrc.1, torrc.2, torrc.3, etc...) under one non-root user with only two public ports open on the data center network (80 and 443)? I'm getting stuck at the port reachability phase, and even more so when trying to run multiple instances with forwarding/binding warnings. The Application Level Firewall allows certain granted programs (tor/tor-gencert/tor-print-ed-signing-cert/tor-resolve/torify/obfs4proxy) the ability to open or accept a network socket. By editing the macOS network system settings to route port 80 to 9005, and noting ORPort 80 NoListen ORPort 0.0.0.0:9005 NoAdvertise in the torrc, that works correctly (including routing 443 for obfs4proxy). Running a second instance is where it seems to break down. Is there a way to have multiple tor instances sharing a port? My guess is the main issue is that at the system routing level, I need a way to note each IP and port so it goes to the right tor instance. Currently, the forwarding is set up like: rdr pass on en1 inet proto tcp from any to any port 80 -> 127.0.0.1 port 9005 I'm guessing I need some way to designate IP XX.XXX.XX.120 -> port 9005 (torrc.1), XX.XXX.XX.121 -> port 9006 (torrc.2), XX.XXX.XX.122 -> port 9007 (torrc.3), etc. Is that correct? A copy of my notes and configurations so far can be found here: http://5jp7xtmox6jyoqd5.onion/p/ISjeXEW-vt8H1s89bwSW Please feel free to make suggestions or edits directly in that etherpad. I'm sure there are multiple ways to do this, but I definitely want to make sure I am using the most secure method as opposed to the easiest or quickest... Thanks for any help in advance. All the best, Wilton

2 1

Question about authority clock skew
by torjoy 14 Apr '20

14 Apr '20

Hello everyone, how are you? I was browsing the "Consensus health" page and something let me curious... What is the importance of the clock skew in the authorities with the resolution of microseconds? Picture: 2020/04/13 - 13:37 UTC Also, how the authorities compare their clocks? Using ntp daemon for example? I'm asking this here because I work in a time and frequency reference lab and have two NTP (stratum 1, connected directly to UTC(LRTE) timescale. And a stratum 2 that is discilplinned with the stratum 1 timeserver). So considering the microssencond accuracy did the keepers of these authorities care about the time source? Or any time source is ok? Best regards and keep safe! Luiz

4 5

Introducing: The Onion Pack
by Ralph Wetzel 10 Apr '20

10 Apr '20

8 11

Bridge is down
by Anonforpeace 10 Apr '20

10 Apr '20

Hello: Hope someone can help. I had a power outage the other night and when I turned on my bridge the next day, I found that I have no connectivity. It is hard wired and among all other computers, it is the only one that is offline. The logs which are attached here state that it cannot finish the bootstrapping process. My browser also does not surf. I can get an IP address but that's as far as it gets. I'm having trouble deciphering the log files. Any help is appreciated. Thanks

3 3

Sudend drop in Consensus Weight
by Clément Février 08 Apr '20

08 Apr '20

Hello, On April 5th, the consensus weight of my tor relay dropped to 0, see https://metrics.torproject.org/rs.html#details/33D88F331408141F2A2CC563239E… As far as I know, nothing specific happened, no update nor reboot. Nothing in the logs. Can anyone explain me what happened? Thanks, Clèm

3 3

Advertised Bandwidth vs. RelayBandwidthRate
by petrarca＠protonmail.ch 08 Apr '20

08 Apr '20

Hello all - I see a constant mismatch of my relay regarding the Advertised Bandwidth vs. the defined and available RelayBandwidthRate. Tor metrics usually only shows around 1.3 MiB/s as Advertised Bandwidth (Bandwidth rate: 3 MiB/s, Bandwidth burst: 6 MiB/s). The torrc config defines: RelayBandwidthRate 24 Mbit RelayBandwidthBurst 48 Mbit So everything looks fine, except the Advertised Bandwidth seems to be too low. Fingerprint is 605EE4375EE4C38215C8949F5808863749FD4F4A and there is plenty of bandwidth available (1 Gbps link). The connection is up-and-running perfectly fine without any issues or interruptions for at least a month. Any idea, why the Advertised Bandwidth is so low?

2 3

Guidelines and processes for our bad relay work
by Georg Koppen 08 Apr '20

08 Apr '20

Hello! There has been some confusion among relay operators about how we deal with bad relays and who is actually making decisions and how the overall process is working. Even though we don't have a document yet to point to for answering all those questions (more on that below) we thought it could be useful to give a status update to the relay community and outline possible next steps. One of the tasks in the network health area is to make sure bad relays are found and excluded from the network. This should happen according to transparent criteria which help relay operators to understand both expectations and processes. Ideally, a document containing those criteria would give operators some insight at how we arrived at those as well. Unfortunately and as I said above, we are not at a point yet where we have written up that document. However, that does not mean that removing relays from the network is arbitrary currently. Rather, we have some rules of thumb and some unwritten guidelines which still seem to be worth sharing at this point to help relay operators better understand what is going on in the bad relay detection world. A bad relay is one that either doesn't work properly or tampers with users' connections. This can be either through maliciousness or misconfiguration. We are relying on some scanners that check for common issues to find those relays and on volunteers that spot things beyond what our scanners target. To give you some examples of issues we are concerned about: a) Tampering with exit traffic b) Running HSDirs that harvest and probe .onion addresses c) Issues with resolving DNS queries on exit relays d) Flooding the network with relays to deanonymize users e) Running outdated Tor versions ... Now, how do we detect maliciousness vs. misconfiguration and what do we do about both? There is behavior that we think is clearly malicious like tampering with exit traffic or trying to harvest and probe .onion addresses. In those cases we outright reject relays. In the past we thought relays that tampered with exit traffic could still be useful as non-exit relays and they got the BadExit flag. But it turned out that a bunch of those had other, more subtle, misbehavior and thus we decided to be on the safe side and just reject those malicious relays nowadays. For behavior that could either be malicious or the result of a misconfiguration (like missing MyFamily settings) things get messier. Means for contacting relay operators (e.g. a meaningful ContactInfo entry) are very important in cases where misconfiguration can play a role. We usually contact operators in that case (if possible) to figure out what is going on and help them getting their configurations right. That means there is no outright force removal of relays that e.g. did not have their MyFamily configuration set up properly (we know it can be tricky). That approach is successful in a lot of cases and helps us build a relationship to operators which is worthwhile as well. However, in cases where we don't get a reaction or are getting confident that the intentions of the operator are malicious we'll reject the relay(s) to protect our users. All those activities mentioned above are coordinated on the bad-relays list, which is private and used by members of the team to discuss cases and keep each other in the loop. As to next steps: yes, we need to sit down finishing that document with all the criteria we are concerned with giving some rationale for each of them. Alas, there is no timeframe for getting this work done. But once we are there we'll consult tor-internal and the tor-relays list for input and make changes as needed. I hope this helps to clear some things up. I am happy to answer questions/reply to concerns on and off-list should there be some. Georg

1 0

(FWD) Network is suffering with only two torflows; can you help?
by Roger Dingledine 08 Apr '20

08 Apr '20

FYI, below is a start at a short-term plan to address the current network weighting issues, now that, as of a few weeks ago, gabelmoo's torflow died and Sebastian hasn't been able to get it going properly again. See also nifty's new ticket: https://bugs.torproject.org/33824 --Roger ----- Forwarded message from Roger Dingledine <arma(a)torproject.org> ----- Date: Mon, 6 Apr 2020 06:06:26 -0400 From: Roger Dingledine <arma(a)torproject.org> To: dir-auth <dir-auth(a)lists.torproject.org> Subject: Network is suffering with only two torflows; can you help? tl;dr there's a way at the bottom of this mail that you can help even without running torflow yourself. [...] So, it looks like we're down to two remaining torflows, and because that's less than three, we're suffering much more from the current errors in sbws. Specifically, (a) sbws doesn't vote for some relays, and (b) sbws votes a super low weight for some relays. There are somewhere between 500 and 1000 relays that are getting left out of sbws's opinions: https://consensus-health.torproject.org/#bwauthstatus and then some thousands more that are getting drastically underweighted, per the "Bandwidth Auth Statistics" graphs at the bottom of https://consensus-health.torproject.org/graphs.html Relay operators are sad that their relays are being useless, and thinking about how maybe they should shut them off if nobody's going to use them. I hear from GeKo that the sbws devs are aiming to fix the sbws issues by end-of-April. That's great, but I wonder if there are some short term hacks we can do that will help until then. Option 1: dizum, dannenberg, or tor26 start up a torflow. I'm guessing they would have done this already if they were going to. Option 2: maatuska, longclaw, or bastet switch from sbws to torflow. Is this an workable option for any of you? Option 3: Any of you besides Faravahar start hourly importing a copy of moria1's weights: https://freehaven.net/~arma/bwscan.V3BandwidthsFile and you vote them as though you were running your own torflow, but you don't need your own torflow. Option 3 is pretty wild at first glance -- it violates some trust and independence assumptions. But for those who aren't running a bwauth, you're already not being listened to about bandwidth weights. So I think this would be a fine hack in the short term to rescue the network, while we wait for sbws. Any takers? :) Here's the simple two-step process for testing the idea: (1) Set a "45 0-23 * * *" cron line to wget the above freehaven url. (2) In your torrc, set "V3BandwidthsFile /path/to/that/bwfile" If you like the idea, and it's just the wget that's too sketchy for you, I can set up an ssh account that just dumps the file at you when you present the right ssh key. Or for super overkill, you'll notice that moria1's (signed) vote has these two lines it: bandwidth-file-headers timestamp=1586162183 bandwidth-file-digest sha256=24+52C1ItwnAyBTtBteyy6tjxk8JnUpQ/XZx3YStEXE so with some stem or shell programming we should be able to verify the file itself, rather than just verifying the place it came from. We could be getting away from "short-term hack" there though. :) --Roger ----- End forwarded message -----

1 1

Relay in a stop/start loop
by Totor be 07 Apr '20

07 Apr '20

Hi list I have upgraded recently my relays (totorbe*) to CentOS8 + tor 0.4.2.7 and they all seemed to run properly This morning, I just noticed a weird behavior on one of them (no idea since when this is going on) When starting tor, it goes to the point of IP identification and then starts shutting down ("Interrupt: we have stopped accepting new connections...") It attempts then to restart immediately and loops start --> interrupt --> start etc... Any idea where too start investigating?? [root@totorbex tor]# cat notices.log Apr 06 10:32:47.000 [notice] Starting with guard context "default" Apr 06 10:32:47.000 [notice] Signaled readiness to systemd Apr 06 10:32:47.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Apr 06 10:32:47.000 [notice] Guessed our IP address as 82.212.170.79 (source: 128.31.0.34). Apr 06 10:32:48.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Apr 06 10:33:17.000 [notice] Clean shutdown finished. Exiting. Apr 06 10:33:18.000 [notice] Tor 0.4.2.7 opening log file. Apr 06 10:33:18.719 [notice] Tor 0.4.2.7 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. Apr 06 10:33:18.719 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Apr 06 10:33:18.719 [notice] Read configuration file "/usr/share/tor/defaults-torrc". Apr 06 10:33:18.719 [notice] Read configuration file "/etc/tor/torrc". Apr 06 10:33:18.723 [notice] Based on detected system memory, MaxMemInQueues is set to 5791 MB. You can override this by setting MaxMemInQueues by hand. Apr 06 10:33:18.724 [notice] Opening Socks listener on 127.0.0.1:9050 Apr 06 10:33:18.725 [notice] Opened Socks listener on 127.0.0.1:9050 Apr 06 10:33:18.725 [notice] Opening Control listener on 127.0.0.1:9051 Apr 06 10:33:18.725 [notice] Opened Control listener on 127.0.0.1:9051 Apr 06 10:33:18.725 [notice] Opening OR listener on 0.0.0.0:9001 Apr 06 10:33:18.725 [notice] Opened OR listener on 0.0.0.0:9001 Apr 06 10:33:18.725 [notice] Opening Directory listener on 0.0.0.0:9030 Apr 06 10:33:18.725 [notice] Opened Directory listener on 0.0.0.0:9030 Apr 06 10:33:18.000 [notice] Not disabling debugger attaching for unprivileged users. Apr 06 10:33:20.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Apr 06 10:33:20.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Apr 06 10:33:20.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Apr 06 10:33:21.000 [notice] Your Tor server's identity key fingerprint is 'TotorBEx E514A3818BC87E87B0B82B6494672F69CED5350D' Apr 06 10:33:21.000 [notice] Bootstrapped 0% (starting): Starting Apr 06 10:34:00.000 [notice] Starting with guard context "default" Apr 06 10:34:00.000 [notice] Signaled readiness to systemd Apr 06 10:34:00.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Apr 06 10:34:00.000 [notice] Guessed our IP address as 82.212.170.79 (source: 128.31.0.34). Apr 06 10:34:01.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Apr 06 10:34:30.000 [notice] Clean shutdown finished. Exiting. Apr 06 10:34:31.000 [notice] Tor 0.4.2.7 opening log file. Apr 06 10:34:31.721 [notice] Tor 0.4.2.7 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. Apr 06 10:34:31.721 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Apr 06 10:34:31.721 [notice] Read configuration file "/usr/share/tor/defaults-torrc". Apr 06 10:34:31.721 [notice] Read configuration file "/etc/tor/torrc". Apr 06 10:34:31.725 [notice] Based on detected system memory, MaxMemInQueues is set to 5791 MB. You can override this by setting MaxMemInQueues by hand. Apr 06 10:34:31.726 [notice] Opening Socks listener on 127.0.0.1:9050 Apr 06 10:34:31.726 [notice] Opened Socks listener on 127.0.0.1:9050 Apr 06 10:34:31.726 [notice] Opening Control listener on 127.0.0.1:9051 Apr 06 10:34:31.727 [notice] Opened Control listener on 127.0.0.1:9051 Apr 06 10:34:31.727 [notice] Opening OR listener on 0.0.0.0:9001 Apr 06 10:34:31.727 [notice] Opened OR listener on 0.0.0.0:9001 Apr 06 10:34:31.727 [notice] Opening Directory listener on 0.0.0.0:9030 Apr 06 10:34:31.727 [notice] Opened Directory listener on 0.0.0.0:9030 Apr 06 10:34:31.000 [notice] Not disabling debugger attaching for unprivileged users. Apr 06 10:34:33.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Apr 06 10:34:33.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Apr 06 10:34:33.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Apr 06 10:34:34.000 [notice] Your Tor server's identity key fingerprint is 'TotorBEx E514A3818BC87E87B0B82B6494672F69CED5350D' Apr 06 10:34:34.000 [notice] Bootstrapped 0% (starting): Starting Apr 06 10:35:13.000 [notice] Starting with guard context "default" Apr 06 10:35:13.000 [notice] Signaled readiness to systemd Apr 06 10:35:13.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now.

3 3

Doubt related to Bridge relay
by Ismael Castro 07 Apr '20

07 Apr '20

Hi, I'm new to setting up a relay but I'd like to help the Tor Network. I have some, perhaps silly, doubts: 1. Can I use tor browser from the same computer the bridge relay node is set up? Navigation will remain anonymous (at least similar than when using only tor browser)? 2. Will I notice any decrease or increase in tor network navigation speed? (understanding that I'll previously set up a max bandwidth to the node) 3. Any other concern I should be aware of? Thanks!!

3 2

Is this probing normal for a bridge
by Eddie 07 Apr '20

07 Apr '20

Hi, On the VPS where I run a couple of bridges, I often see the following: tcp6 0 0 aaa.bbb.cc.dd:443 194.14.247.1:18913 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:18457 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:29917 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:23629 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.247.1:8846 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:11833 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:20856 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.247.1:38085 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.246.1:60957 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:10471 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:60852 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.246.1:45321 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.246.1:43384 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:31634 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:29895 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:51774 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:27223 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.246.1:11116 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.0.1:31465 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:30646 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.246.1:11117 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:46609 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.247.1:57978 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:59133 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:27371 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:13364 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:50336 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:34511 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:80 aa.bb.ccc.dd:59349 ESTABLISHED tcp6 0 0 aaa.bbb.cc.dd:443 194.14.0.1:20251 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:11573 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.0.1:37358 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:44226 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:59194 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.14.165.1:38300 SYN_RECV tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:18209 SYN_RECV Is this normal probing by the script kiddies or is it specific because I'm running the bridges. Cheers.

2 1

Update on the status for sbws (simple bandwidth scanner)
by Georg Koppen 07 Apr '20

07 Apr '20

Hello everyone! Some of you might have read about relay operators being affected by a drop of bandwidth on their relays recently or might even have hit this problem themselves. Bug 33775[1] has more details about what is going on (in short: sbws, our new bandwidth scanner, has still release critical bugs but the instances running it got recently the voting majority as Torflow is showing its age and the duct tape around it is wearing off). Roger forwarded a mail to this list yesterday as well about short term hacks to solve this problem[2]. Things are looking good at that front so far. We are optimistic that the situation is getting better substantially rather soon as some of our directory authorities are either switching right now to using Torflow data again or making progress in resolving their Torflow related issues that prevented them from running it. We thought it would be helpful to give an update about our remaining sbws work as well. So, the good news here is that we aim to have all the critical bugs fixed by end of April (yes, this month :)). Right now we know of the following five: #33350[3] #33775[4] #30735[5] #33009[6] #30719[7] We have the last two in `needs_review` (the last one via #30905[8]) and are currently distributing the first three among developers working on sbws, so we can work in parallel on them. There is the risk that behind those bugs some other critical bugs lurk, which we have not found yet. To mitigate that we'll switch one bandwidth authority to running sbws's git master branch so we detect those bugs as early as possible should they exist. Finally, we are working on a proper transition plan away from Torflow to avoid mistakes we've made so far and provide as little friction as possible for all parties involved in the whole process. Let us know if you have any questions. Either way, I hope I could get the point out that the current situation is worked on and temporal. There is no need to shut down relays as the result of the current issues. :) Georg [1] https://trac.torproject.org/projects/tor/ticket/33775 [2] https://lists.torproject.org/pipermail/tor-relays/2020-April/018337.html [3] https://trac.torproject.org/projects/tor/ticket/33350 [4] https://trac.torproject.org/projects/tor/ticket/33775 [5] https://trac.torproject.org/projects/tor/ticket/30735 [6] https://trac.torproject.org/projects/tor/ticket/33009 [7] https://trac.torproject.org/projects/tor/ticket/30719 [8] https://trac.torproject.org/projects/tor/ticket/30905

1 0

Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
by Keifer Bly 02 Apr '20

02 Apr '20

2 4

Tor fingerprint backup
by Kolja Sagorski 02 Apr '20

02 Apr '20

Hello together. I have a problem. When I install a fresh debian server and a new tor relay, I can’t restore my fingerprint. I have the fingerprint file and the key folder. I stopped the new relay. Insert and replace the fingerprint and Key Folder. After that, the server didn’t start now :( Can anyone help me? Kind regards, kolja.

2 2

Re: [tor-relays] Low bandwidth
by ha3ks 01 Apr '20

01 Apr '20

Hi, The fingerprint is - 6E1DA4C0B0C05FB721B42329C47A20DA22908AEB I have followed some of this yes, though its a little over my head Thanks - Dan Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, 31 March 2020 10:10, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: Low bandwidth (teor) > 2. Re: Possible to run a tor bridge/relay via tor browser? > (Keifer Bly) > > > Message: 1 > Date: Tue, 31 Mar 2020 09:44:41 +1000 > From: teor teor(a)riseup.net > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Low bandwidth > Message-ID: 19B3A11C-D7CB-4B20-8319-8494A1FF0271(a)riseup.net > Content-Type: text/plain; charset="utf-8" > > Hi, > > > On 30 Mar 2020, at 23:00, ha3ks ha3ks(a)protonmail.com wrote: > > my relay dropped nearly all it’s bandwidth about a month ago, checking over it I can see 3 of the dir auths have given it a low consensus weighting, would that cause low bandwidth numbers? > > I checked my ufw in Ubuntu and it’s allowing 443 and 80. > > I have seen similar reports from a few other relay operators. > > What is your relay fingerprint? > > Have you followed the troubleshooting instructions here: > https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow > > T >

4 3

Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
by Keifer Bly 31 Mar '20

31 Mar '20

2 2

Low bandwidth
by ha3ks 30 Mar '20

30 Mar '20

Hi my relay dropped nearly all it’s bandwidth about a month ago, checking over it I can see 3 of the dir auths have given it a low consensus weighting, would that cause low bandwidth numbers? I checked my ufw in Ubuntu and it’s allowing 443 and 80. Any help is greatly appreciated. Thanks Dan Sent from ProtonMail Mobile

2 1

Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
by Keifer Bly 30 Mar '20

30 Mar '20

2 3

Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
by Keifer Bly 30 Mar '20

30 Mar '20

2 1

Moving my obfs4 bridge from tor expert bundle to Debian, and have some questions. Thanks.
by Keifer Bly 30 Mar '20

30 Mar '20

Hi all, So I am switching the OBFS4 bridge I was running via Tor Expert Bundle on Windows 10 over to running it via Debian app for Windows 10. This app is on the Windows store at https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?activetab=pivot:overv… Essentially, it is an app that lets you run Linux packages on Windows. I made the switch so that I could keep tor and obfs4 up to date using unattended upgrades. However, for some odd reason, despite the fact I backed up the tor identity keys and pasted them into the keys directory when I moved over, the bridge is still generating new keys on startup. I copied the key files from my expert bundle bridge to /var/lib/tor/keys directory in the Linu terminal, I copied all of the files. It’s a bridge so no big deal I guess, but wonder why that is happening. https://metrics.torproject.org/rs.html#details/780F4E3ADBC574A63CE8155C0911… And, I tested to see of unattended upgrades was working correctly after configuring it with these instructions: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpd… And got this the attached photo as a result, does this mean it is keeping tor and obfs4 up to date? Thanks very much. tor update test.PNG <https://drive.google.com/file/d/1c5TinBlApx5YuObiwt8pkl9w_F74O0JL/view?usp=…> --Keifer

2 4

BadExit
by gerard＠bulger.co.uk 29 Mar '20

29 Mar '20

Oh the shame! Never had that tag on my exit before. I assume it was due to a bad boy attacking an IP, pointed out by my ISP, and the ISP put my server "under mitigation". I assume some filtering, which of course would have looked bad to TOR users. I did not spot the ISP's email for 30 minutes, but then I was able to block the offended IP. Within minutes of doing that the ISP said attack stop and my server was removed from mitigation. However the next day badexit tag on my exit and remains there How long does the tag last? I go to my other, overseas exit, a family member, to see the tag is aslo applied there to. Do family members get tarred with the same brush? I have turned both into relays for the time being. Or have I got this wrong. Is it a DNS thing? Are no some DNS providers causing issues forcing the tag? I am not using opendns. Gerry

5 12

Moving my obfs4 bridge from tor expert bundle to Debian
by Keifer Bly 29 Mar '20

29 Mar '20

1 0

Possible to run a tor bridge/relay via tor browser?
by Keifer Bly 29 Mar '20

29 Mar '20

2 3

Problem with ubuntu 18.04 x386
by Francisco 29 Mar '20

29 Mar '20

I make the installation following the official page torproject.org from the tor repositories. I edit de torrc file and save the changes. but when i restart the service, gives me error. $ systemctl status tor@default failed (Result: exit-code) since... systemd[1]: tor(a)default.service: Start request repeated too quickly. systemd[1]: tor(a)default.service: Failed with result 'exit-code'. systemd[1]: Failed to start Anonymizing overlay network for TCP. thanks in advance. Sent from ProtonMail mobile

5 4

Re: [tor-relays] Problem with ubuntu 18.04 x386
by Francisco 29 Mar '20

29 Mar '20

Hi, sorry for that, I'm sending more information now: Tor version: Tor 0.4.2.7 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. The log when I try to restart the service (sudo systemctl restart tor@default) : Job for tor(a)default.service failed because the control process exited with error code. See "systemctl status tor(a)default.service" and "journalctl -xe" for details. $ systemctl status tor(a)default.service tor(a)default.service - Anonymizing overlay network for TCP Loaded: loaded (/lib/systemd/system/tor(a)default.service; enabled-runtime; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2020-03-29 14:25:21 -03; 4min 55s ago Process: 2587 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --ver Process: 2586 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /run/tor (code=exited, status=0/SUCCESS) mar 29 14:25:21 x systemd[1]: Failed to start Anonymizing overlay network for TCP. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Service hold-off time over, scheduling restart. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Scheduled restart job, restart counter is at 5. mar 29 14:25:21 x systemd[1]: Stopped Anonymizing overlay network for TCP. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Start request repeated too quickly. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Failed with result 'exit-code'. mar 29 14:25:21 x systemd[1]: Failed to start Anonymizing overlay network for TCP. $ journalctl -xe mar 29 14:25:21 x systemd[1]: tor(a)default.service: Failed with result 'exit-code'. mar 29 14:25:21 x systemd[1]: Failed to start Anonymizing overlay network for TCP. -- Subject: Unit tor(a)default.service has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit tor(a)default.service has failed. -- -- The result is RESULT. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Service hold-off time over, scheduling restart. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Scheduled restart job, restart counter is at 5. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Automatic restarting of the unit tor(a)default.service has been scheduled, as the result for -- the configured Restart= setting for the unit. mar 29 14:25:21 x systemd[1]: Stopped Anonymizing overlay network for TCP. -- Subject: Unit tor(a)default.service has finished shutting down -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit tor(a)default.service has finished shutting down. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Start request repeated too quickly. mar 29 14:25:21 x systemd[1]: tor(a)default.service: Failed with result 'exit-code'. mar 29 14:25:21 x systemd[1]: Failed to start Anonymizing overlay network for TCP. -- Subject: Unit tor(a)default.service has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit tor(a)default.service has failed. -- -- The result is RESULT. mar 29 14:29:38 x kernel: perf: interrupt took too long (3160 > 3140), lowering kernel.perf_event_max_sample_rate to 63250 mar 29 14:30:17 x sudo[2616]: fcp : TTY=pts/0 ; PWD=/home/fcp ; USER=root ; COMMAND=/bin/systemctl status tor@default mar 29 14:30:17 x sudo[2616]: pam_unix(sudo:session): session opened for user root by (uid=0) mar 29 14:32:07 x sudo[2616]: pam_unix(sudo:session): session closed for user root Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, March 29, 2020 9:00 AM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Problem with ubuntu 18.04 x386 (Francisco) > 2. Re: Problem with ubuntu 18.04 x386 (TorGate) > > > Message: 1 > Date: Sun, 29 Mar 2020 06:31:48 +0000 > From: Francisco franciscort(a)protonmail.com > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Problem with ubuntu 18.04 x386 > Message-ID: > TmgFQrqhT-AZx7PXSZ5VGxxkmeI-Xf869hC1IKYE6itAhAZwpgjfJ-jkkcNCKUNC4GaHzRi4gLCO91k1K9xPRajp-5hAg6aJEYUFvoNvPtc=(a)protonmail.com > > Content-Type: text/plain; charset="utf-8" > > I make the installation following the official page torproject.org from the tor repositories. > > I edit de torrc file and save the changes. but when i restart the service, gives me error. > > $ systemctl status tor@default > failed (Result: exit-code) since... > > systemd[1]: tor(a)default.service: Start request repeated too quickly. > systemd[1]: tor(a)default.service: Failed with result 'exit-code'. > systemd[1]: Failed to start Anonymizing overlay network for TCP. > > thanks in advance. > > Sent from ProtonMail mobile >

2 1

Re: [tor-relays] Possible to run a tor bridge/relay via tor browser?
by Keifer Bly 27 Mar '20

27 Mar '20

1 0

New relay
by William Pate 27 Mar '20

27 Mar '20

Set up another relay (this time on Raspberry Pi 4): https://metrics.torproject.org/rs.html#details/BD187CF1B44A84EC7DD1BC2AC9C4… William Pate willpate(a)pm.me 512-947-3311 inadequate.net

2 2

tor on Centos version question
by torix＠protonmail.com 24 Mar '20

24 Mar '20

I can see that my Debian relay went from 0.4.2.6 to 0.4.2.7 a few days ago automatically with auto updates set up. However, my hosted relay, which runs on Centos 7, is still at version 0.3.5.8. I am using the epel repo version. Is that okay? Or should I have added a tor repo? TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

Re: [tor-relays] Dirport9030
by Nuno Rego 24 Mar '20

24 Mar '20

As I said, I'm still learning. I have a server at Hetzner with a monthly limit of 20TB, and I am trying to adjust the speed so that it does not exceed 20TB at the end of the month. The problem is that whenever I place the BandwidthRate and BandwidthBurst above 10MB I lose the Guard, HSdir and V2Dir flags. On the page https://metrics.torproject.org/rs.html#search/TugaOnion I see that DirPort is 0 instead of 9030. I have the BandwidthRate and BandwidthBurst at 9MB and everything is fine, but I will reach the end of the month and I only spent about 10TB. Cumprimentos; TugaOnion -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com Mar 4, 2020, 21:37 by : > I have a problem.> > I am learning, and I have 4 active relays.> > I used the same configuration on the 4. Recently 2 of them lost the Guard, HSdir and V2Dir flags.> > On the page > https://metrics.torproject.org/rs.html#search/TugaOnion> I see that DirPort is 0 instead of 9030. I haven't changed anything, and in the relay configuration there is 9030. Any suggestions on how to solve the problem> > ? > > Cumprimentos; > > -- > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: > https://tutanota.com >

3 3

Is it wise to continue to allow yahoo email accounts to request bridges?
by Keifer Bly 23 Mar '20

23 Mar '20

Hi all, So for those who did not know, Yahoo (and as such Yahoo Mail) is now owned by Verizon. They bought both Yahoo and AOL and combined them into Verizon Media. For this reason, it seems like allowing Yahoo Mail accounts would in turn allow a large scale ISP (in this case Verizon) to easily obtain bridges. Does anyone agree on this? It's just a thought. Thanks. --Keifer

2 1

Re: [tor-relays] Stable flag not appearing on my bridge.
by Keifer Bly 23 Mar '20

23 Mar '20

2 2

Relay Or/Dirport Unreachable
by Kathi 23 Mar '20

23 Mar '20

Plan: Configure relay on local cable connection (Century Link). The idea is to have the relay proofed operational the way I want it and then move it (torrc) to a droplet after it has been in operation for three days. Doing this saves cost in downloading to the droplet. Modem Zyxel C3000 _was_ set to port forward on 9001, 9030, and 9050 IP 192.XXX.X.X Turn off UpnP (plug and play) <relay fails with it on> GUFW is set to allow the above ports – reload to allow changes after much struggling/research to open ports 9001/9030 nc -zv 127.0.0.1 9001/9030 Connection to 127.0.0.1 9001 port [tcp/*] succeeded! <9030 also> Alrighty then! Tor –verify-config <many probs here, but cleared> No complaints NOTE: I know tor.Nyx should not be run as root, I get that. Tor/Nyx are running as root. I don’t know how to use debian-tor as usr. Nyx shows in it’s configuration as usr debian-tor. Su debian-tor produces a rollover back to root usr prompt. service tor start Nyx – No complaints, running as default. After just two minutes of operation the relay was running at 2 MB/s with bursts up to 3 MB/s. After the obligatory/frustrating twenty minute wait for or/dirport hand shaking I get:orport/dirport unreachable…. Adnauseum! Changed IP address to one given by tor, still unreachable. Lastly, I removed the 900l/9030 ports from the modem and installed 6969 as the orport. Changed GUFW, verified the changes took place, changed ip to real world IP 63.xxx.xxx.xxx in torrc. Hand shaking to the orport was almost immediate. Right now, the relay after twenty hours of operation is tortusing along at 20 B/s. Which to me is pure BS. Can someone give me some idea’s as to what I am doing wrong? Kathi

7 10

When will my relay gain the stable flag again?
by nottryingtobelame＠protonmail.com 18 Mar '20

18 Mar '20

My relay (903CA67D0DEB74CFBB01432840A26CB8C6C18FDF) is ~2 years old. Recently, I had a series of network issues that took my relay offline for unexpectedly long times. When it has gone offline before and lost the stable flag, it usually took only a couple days to pick it back up again. It is approaching 8 days since I finally got things resolved with a new router, but still no stable flag. I also used to have the guard flag, but I know I can't get back to guard status without the stable flag. Thanks.

2 1

When will my relay gain the stable flag again?
by nottryingtobelame＠protonmail.com 18 Mar '20

18 Mar '20

Disregard - the relay picked up the stable flag tonight.

1 0