- tor-relays - lists.torproject.org

Relay Name Change
by Kathi 10 Apr '21

10 Apr '21

I changed the name of my relay nick name from <UnNamed> to (Correct Name) after I got it to operate correctly. The relay was in operation when I did the change. I went into the menu in NYX, clicked reset tor. The relay has been up eighteen hours as of this writing. Its flags are: Fast, Running, V2Dir, Valid.1,911 circuits open and 2709 outbound, 20,670 connections on Ivp4 Tor Metrics shows <Unnamed> only (Correct Name) isn't shown when searched How long does it take for the name change to take effect? sysop

4 3

Possible to give something I made to tor? (message for roger digeldine and other tor project heads)
by Keifer Bly 10 Apr '21

10 Apr '21

Hi all, So for the sake of diversity, as well as helping out Windows users who want to contribute to tor, this is a tool I have created which makes running tor relays on Windows very easy. The features are: Auto installs tor and keeps it up to date. Easy relay configuration with provided torrc file. Can configure to start relay on OS boot. The drawbacks is it configures the Windows Defender Firewall to allow the relay traffic but can't auto configure any other firewalls, and only supports vanilla bridges currently. I am wanting to give this tool to tor project to list on the website for those looking to run relays on Windows networks (networks running Windows Server, etc). I've made this GUI open source with a GitHub link, if interested. Thanks. --Keifer

1 0

IPv4 AND IPv6 Relay
by ML Tor 09 Apr '21

09 Apr '21

Hi to all. I have recently created 4 TOR relays on two different ISPs (frantech.ca and yourserver.de). They work smoothly with IPv4. Now I wanted to add IPv6 as well, as both ISPs provide a / 64 address. In my torrc file I have inserted these two lines: ORPort nnnn.nnnn.nnnn.nnnn: 8001 ORPort [2605: 6400: 10: 55c: 199: 195: 250: 83]: 8001 But I get this error: "[NOTICE] Unable to find IPv6 address for ORPort 8001. You might want to specify IPv4Only to it or set an explicit address or set Address." Then only the IPv4 address is enabled. I have done various tests but I cannot find the solution. Can you tell me the correct configuration? :-) -- F1D75392BBB9E8D165A918F7DC8E270BCA67D720 9EA17159838F930F4D63757692AC2CE06C45D30E F02D242E78E099DFA30AE9C90E47D61C170EE97C 3160C0AA71A17811246FDCEAB246326C7D9ED754

2 1

Fallback Directories - Upcoming Change
by David Goulet 08 Apr '21

08 Apr '21

Greetings! This is to announce that the Tor Project network team will soon change how fallback directories are selected as we are about to update that list. As a reminder, here is the fallback directory definition from the tor man page: When tor is unable to connect to any directory cache for directory info (usually because it doesn’t know about any yet) it tries a hard-coded directory. Relays try one directory authority at a time. Clients try multiple directory authorities and FallbackDirs, to avoid hangs on startup if a hard-coded directory is down. Clients wait for a few seconds between each attempt, and retry FallbackDirs more often than directory authorities, to reduce the load on the directory authorities Previously, we would ask this list for volunteers and then start a lengthy process over weeks to add/remove volunteers from an official list and then make sure the volunteered relays were matching a certain set of criteria. This process was very time consuming for our small team and so we are making a change to be more efficient and avoid to slip on the updates like we did in the previous versions. We will now select at random relays to become fallback directories that match those requirements: - Fast flag "Fast" -- A router is 'Fast' if it is active, and its bandwidth is either in the top 7/8ths for known active routers or at least 100KB/s. - Stable flag "Stable" -- A router is 'Stable' if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF corresponds to at least 7 days. - DirCache is set to 1 (default) - As been around for at least 90 days. The above corresponds to more than 4000 relays at the moment in the consensus and so we'll randomly pick 200 from those at each release so we can have regular rotation and shift load over time over the entire network. Over time, we will remove or add more relays at each minor release if the set of fallback directories not working reaches a 25% threshold or more. Finally, it is very possible that we'll change those requirements over time as we assess this change. We'll do our best to inform this list in time. Thanks! Tor Network Team -- fegt0kLbq3rSb5UY2KTCr5TVsjOd2mko2FRZAZic23Q=

3 3

How best to convince people not to block Tor entirely when they cite DDOS attacks as the reason?
by Nils Erik Flick 07 Apr '21

07 Apr '21

Hi everyone, (Tor advocacy vs. panicked small-time hosting company suffering from "massive attacks") What advice can I offer to someone who's blocking traffic from Tor because their network is apparently experiencing sustained DOS attacks via some exits? They explained to me that they were aware of the value of anonymity online, but couldn't see a way to protect their hosting customers from "attacks making the systems inaccessible". In the end I offered some vague handwaving ("why don't you temporarily throttle traffic just from the nodes where the attacks come from"). I'm not going to do *their* job. But it would still be useful to have something better to point to than just a vague remark. This is a situation where the standard reasons why one needn't block Tor don't really work, and next time I'd like to be better prepared to argue why this isn't a reason either. So, is there some ready-made explanation I could send to such a company, that explains in technical detail how they can *properly* mitigate this without overblocking? K.

1 0

Relay Configurator
by Андрей Гвоздев 06 Apr '21

06 Apr '21

Did anyone use this website: https://tor-relay.co Is it safe to use? Is there an easy way to setup MyFamily if you want to run a few relays?

2 1

Relay Search without AS number/name information?
by nusenu 05 Apr '21

05 Apr '21

Hi, as many of you know AS level data (AS number and name) on Relay Search/onionoo is using a rather outdated geoip database from maxmind. That is the reason why Relay Search displays inaccurate or no AS information for many relays. Recently the geoip database used by tor (not Relay Search) switched [1] from maxmind's db to ipfire [2] for license reasons. Since tor only needs the country level information in only ships country level informat (but ipfire's geoip also contains AS level data). Today I read about the idea to remove AS level data from onionoo/Relay Search on the gitlab issue: https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40004#note_… If you also have an opinion on whether Relay Search should improve its AS level information instead of removing it completely now is probably a good time to state it - especially if your tools depend on it. kind regards, nusenu [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/40224 [2] https://location.ipfire.org/ -- https://nusenu.github.io

1 0

ISP
by Андрей Гвоздев 05 Apr '21

05 Apr '21

Which ISP is better? Scaleway or OVH?

6 6

We will start a test run with M1
by niftybunny to-surf-and-protect.net 04 Apr '21

04 Apr '21

Hi there, next week we will drop the first M1 Mac Minis in the datacenter. With the thread of bugs in the current BSD version of tor: Any known issue with the Mac version of Tor? Any other suggestions / comments from Tor relay operators with Macs? nifty

1 0

Many SSH requests
by Cristiano Kubiaki Gomes 03 Apr '21

03 Apr '21

Hi there, O noticed many ssh requests to my Debian VM running a Relay and I am wondering if this is normal or if this is happening only with me. Anyone else see this ssh attemptives? Is it normal? sshd[27004]: Failed password for root from 45.91.226.235 port 41012 ssh2 sshd[27004]: Received disconnect from 45.91.226.235 port 41012:11: Bye Bye [preauth] sshd[27004]: Disconnected from authenticating user root 45.91.226.235 port 41012 [preauth] sshd[27006]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=108.36.253.227 user=root It's many different ips and trying to access in many different ports. Thank you!

7 8

syn flood iptables rule
by Toralf Förster 02 Apr '21

02 Apr '21

The following 3 statements # Make sure NEW incoming tcp connections are SYN packets; otherwise we need to drop them. $IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP # DDoS $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood --set $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood --update --seconds 60 --hitcount 10 -j DROP seems to work and to help here ata fast Tor relay. CPU went down from 109% to 95%. There're 500 connections less than before for a Tor fast relay. The /proc/net/xt_recent/synflood is quickly filled. Unfortunately I cannot change the "ip_list_tot" of "xt_recent" b/c I do use a non-modular kernel. Does anybody knows a circumvention? Are there any objections against this approach? -- Toralf

5 9

Is OVH a safe vps provider to run an exit relay on?
by Keifer Bly 02 Apr '21

02 Apr '21

7 9

bridge static or dynamic ip and multiple bridge config
by gi vi an 02 Apr '21

02 Apr '21

does bridge require static or dynamic ip? if more than one bridge can be configured per one isp connection, how do i configure? -- who am i ? https://mstdn.social/@gvian donate or patron: [+]₿ bitcoin (BTC): 3K7Ba2DFyyuGTukNqXEmogG4VgYp2RWnZV [×]gridcoin (GRC): SK7A2yq4rsoDSKc592dxSb3JSYeSSopbNB [÷]Ᵽ peercoin (PPC): PENnyj6dvEqaAKtqh9tV9KzRKc4N5EWfeH [=]pivx (PIVX): DNyihy8xWXkGyaLnipzWUrC3kjrbcvahHJ [<]blackcoin (BC): B4pCYCRhS6itEs2rsSAVbRnoKkL6thj3Bt

5 7

DirPortFrontPage file '.....' not found | Permission denied
by Petrusko 02 Apr '21

02 Apr '21

Hey, I'm having a little problem with setting up (my be some rights...) the html page on the relay DIRPort. On my logs : 00:00:03 [NOTICE] Tor 0.4.5.7 opening new log file. 00:00:03 [WARN] Could not open "/var/www/html/tor-relay.html": Permission denied 00:00:03 [WARN] DirPortFrontPage file '/var/www/html/tor-relay.html' not found. Continuing anyway. I've not found any information about how to set up this correctly. Many thanks in advance.

4 4

ipv6 ORPort + DIRPort too ?
by Petrusko 01 Apr '21

01 Apr '21

Hey, I've set up a new relay, available with ipv4 and ipv6. And I'm not sure if I can serve DIRPort on the ipv6 too ? In the torrc file, I've config : ORPort 9001 ORPort [xxxx:xxxx:xxx:x:xxxx:xxxx:xxxx:xxx]:9001 DIRPort 9030 Is it allowed to add something like this, to advertise on ipv6 too ?? : DIRPort [xxxx:xxxx:xxx:x:xxxx:xxxx:xxxx:xxx]:9030 Thank you all !

4 7

Help with FreeBSD relays
by xplato 31 Mar '21

31 Mar '21

Greetings, I am a bit of a noob here so please bear with me. I ran a relay using Ubuntu with very few issues however I decide to add an additional relay and decided to use FreeBSD. They will only run for around 18 hours and then they shut down. I have adjust the torrc file every way I know how and increased the Max vnodes thinking this may have been my issue. I can post the sysrc and torrc if needed. Anyone that might help me figure this out I would be grateful otherwise I am going to reluctantly move them both back to Ubuntu. Thanks, Dan Sent from ProtonMail for iOS

5 13

relay impersonation (contactinfo)
by nusenu 31 Mar '21

31 Mar '21

Hi, I'd like to raise your awareness of an ongoing scheme of questionable entities that make use of your name or relay contactinfo and/or relay nicknames. Those using other people's relay _nicknames_ got and get spotted by multiple people already and are somewhat obvious (at least for now), but I'd like to highlight those using familiar names in contactInfo that are likely less frequently uncovered because people lookup their relays by searching for their relay nicknames (and not so often by searching their contactinfo). So here are two practical things that you can do to help uncover more of them: - list your relay fingerprints under the well-known tor-relay URI: https://<your domain>/.well-known/tor-relay/rsa-fingerprint.txt and add "url:<your domain> proof:uri-rsa ciissversion:2" to your ContactInfo to allow for automated linkability verification. This protects your relays against spoofing of the url field. A domain is not required: You can use github-pages or similar if you do not have a domain. more details: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/326-… https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ Thanks to the 291 relays, that allow for automated verification already. Verifiable relay groups also get graphs on OrNetStats, for an example see: https://nusenu.github.io/OrNetStats/artikel10.org.html - search for your names/nicknames/org names/... in the ContactInfo field. On Relay Search you can do so using "contact:searchstring" Be creative in your search terms. This even makes sense if you do not run relays at all but your name is somewhat known in this context. kind regards, nusenu -------- Forwarded Message -------- Subject: tor relays rosiwig429(at)lidte(dot)com Date: Tue, 30 Mar 2021 23:55:01 > 2021-03-29 > > | Up | Ext | JoinTime | IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamMembers | FP | > |------+-------+------------+----------------+------------------------------------------+------+-------+--------+-------+-----------+------------------+---------------+------------------------------------------| > | 1 | 1 | 06:25:11 | 103.82.32.14 | CMC Telecom Infrastructure Company | vn | 9001 | 9030 | Linux | 0.4.5.7 | coffswifi5 | 1 | B8D95BB1AAFB6F234EC50A100F46E4CC8E8E90FB | > | 1 | 1 | 07:34:40 | 78.138.135.110 | Ojsc oao Tattelecom | ru | 9001 | 9030 | Linux | 0.4.5.7 | artikel5ev3b2 | 1 | 771C9BC56DF4B29BA97CAA9387FB1FC140CFE3E3 | > | 1 | 1 | 13:43:04 | 103.56.156.143 | VNPT Corp | vn | 9001 | 9030 | Linux | 0.4.5.7 | CalyxInstitute18 | 1 | 04998AB63A49C4A0B5A5CD2994D95D098D2B5399 | > | 1 | 1 | 14:28:18 | 77.245.158.134 | Niobe Bilisim Teknolojileri Yazilim San. | tr | 9001 | 9030 | Linux | 0.4.5.7 | Merlin2 | 1 | B4285A497939D190739C976B947053D6CC0AE07C |

1 0

Re: [tor-relays] ISP (?????? ???????)
by Mark Murray 31 Mar '21

31 Mar '21

I used to run a couple of relays on their DEV1-S instances and never had any problems. They let you use the advertised bandwidth 24/7 without being throttled. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, March 31, 2021 8:26 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. Re: ipv6 ORPort + DIRPort too ? (Petrusko) > 2. This is not me (Paul Templeton) > 3. Re: syn flood iptables rule (Toralf F?rster) > 4. Re: DirPortFrontPage file '.....' not found | Permission > denied (torix(a)protonmail.com) > > 5. ISP (?????? ???????) > 6. Re: Is OVH a safe vps provider to run an exit relay on? > (Volker Mink) > > > Message: 1 > Date: Tue, 30 Mar 2021 21:38:59 +0200 > From: Petrusko petrusko(a)riseup.net > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] ipv6 ORPort + DIRPort too ? > Message-ID: f943db9d-b3c9-e51b-03ea-ac3447f780cf(a)riseup.net > Content-Type: text/plain; charset="utf-8" > > Ouch, this config looks like not so cool... > I see on Metrics the ipv6 choosen by Tor process, is now on : > "Unreachable OR Addresses" > > I'll write the other solution you given previously... with > ORPort xxx.xxx.xxx.xxx:9001 > ORPort [xxxx:xxxx:xxx:x:xxxx:xxxx:xxxx:xxx]:9001 > > 30/03/2021 ? 20:07, Petrusko : > > > Ok ! > > So this only line will serve on both ipv4 and ipv6 together, ok thx ! Cool > > 30/03/2021 ? 15:51, lists(a)for-privacy.net : > > > > > ORPort 9001 > >

1 0

ISP
by Андрей Гвоздев 31 Mar '21

31 Mar '21

Did anyone run relays on Scaleway?

4 3

This is not me
by Paul Templeton 31 Mar '21

31 Mar '21

the relay with fingerprint B8D95BB1AAFB6F234EC50A100F46E4CC8E8E90FB (coffswifi5)is not me... coffswifi4 is mine so don't ask me to add as a family... Paul 137CF322859E400455E457DB920F65FFDD222CDF

2 1

Recent Postings
by manifoil 30 Mar '21

30 Mar '21

Hello fellow Tor Relay operators! Recent activity on this mailing list has given me a headache... Let me explain. I subscribed to this mailing list to keep up to speed with new technical developments, trouble shooting advice and security advisories. If there is a mailing list that covers this criteria, please let me know because that is where I want to be. This recent 'noise' about Mr Stallman is, in my opinion, unnecessary and unwarranted on this particular mailing list. It reminds me of a similar episode on this mailing list a while back where someone appeared to have a personal problem with someone who ran a hosting company - I nearly wrote something about that. My relay has been chugging away at home for many years and bandwidth assigned to the network has steadily increased as my home broadband capability has improved. I am happy that it contributes to Tor and might help people in genuine need - be it politically, racially, sexual orientation wise or as a whistle blower. Finally, I would like to thank the poster who highlighted the OpenSSL vulnerability - my relay was promptly updated. To quote someone else and because I like this persons' sigh-off: With respect, Rattus Norvegicus Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

This past week's most active discussion has forced my hand
by Isaac Grover, Aileron I.T. 30 Mar '21

30 Mar '21

Good morning from Wisconsin, Back in 2019, I was involved in a discussion on this list to seek out hosting providers friendly to Tor exit nodes so that the list on the Tor Project website could be updated and geographic and provider diversity could be improved. Because our twins were newborns at the time, the project took a back burner but I had built up the initial automation and templates for the contacts. Would there be any interest in reviving this project for the aforementioned reasons? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. – “ Because #ProactiveIsBetter ” O: 715-377-0440, F:715-690-1029, W: www.aileronit.com

3 2

Tor [0.4.5.7] {Bridge} IPv4 not found
by Someone 30 Mar '21

30 Mar '21

Hey, I'm running Tor [0.4.5.7] on Ubuntu 20.04.2 LTS and started running my first bridge following the exact tutorials on the community guide for running bridge. However, the syslog says(resulting in non-reachability of the port.): Tor[6278]: Unable to find IPv4 address for ORPort 11120. You might want to specify IPv6Only to it or set an explicit address or set Address. Here's my torrc conf: BridgeRelay 1 ORPort 11120 IPv4Only ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:356 IPv4Only ExtORPort auto ContactInfo __REDACTED_FOR_PRIVACY__ Nickname dubridge Steps done: Saw the router configuration (IPv6 disabled in there). Thought maybe some issue with dynamic/static IP so configured DHCP ADDRESS RESERVATION to get a static IP. Followed a similar thread on this topic by a guy recently so wrote IPv4Only in front of both ORPort and obfs4 Thanks! Someone

2 2

Unsubscribing
by Sebastian Urbach 29 Mar '21

29 Mar '21

Dear list, The last days on this list were stunning, to say the least. I'm going to unsubscribe today and i will decide tomorrow if i shut down all my relays. -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach

5 4

My tool I made which makes running relays on Windows very simple.
by Keifer Bly 28 Mar '21

28 Mar '21

Hi all, So this is a tool I developed for tor which makes running relays on Windows very simple. https://www.youtube.com/watch?v=Vpk6yvUWQqU Features: Example torrc file which can be configured as wanted. Automatically checks if tor is running the newest version on startup, if not updates to newest version. One button configuration to configure relay to start when Windows starts. Generates a tor log file which can tell tor messages. Drawbacks: Only supports vanilla bridges. Configures Windows Defender Firewall automatically to allow tor traffic, but other firewalls will need to be manually configured. Cheers. --Keifer

1 0

Reminder: EOL of my 4 tor relays (2 guards, 2 exits).
by Lisa Winter 28 Mar '21

28 Mar '21

Hello people, Lisa here (not my real name, neither is this my e-mail address - it was not stolen however, the owner allows me to use it -, nor is it associated with any of my relays that you could possibly find on the Tor Metrics page). I used to contribute physical resources to the Tor project for a long time now (I don't want to get into too many details, so let's say somewhere between 4 to 7 years) - paying for the co-location of two high-performance dedicated machines , handling nasty abuse reports, you name it.. Anyway each dedicated server was running two Tor instances occccn each single, public IPv4 and IPv6m as this is the maximum AES hardware acceleration was supported by both physical CPU's, so one instance averaged up to 250mbit/s under full load :-D However, I am sick of all the needless communication with my hosting providers, who are well aware of what I am doing with their equipment, yet idiotic jewbie support still spams me with abuse reports, occasionally null-routing entire IP's which was not part of the conract (I have a custom contract co-locating two, older machines).. I am also sick of the Tor staff allowing companies like Team Cymru (short explanation; Team Cymru collects and sells metadata of network connections but not only metadata, also other "valuable" information like zero-day exploits to anyone willing to pay the right price, and much more - they host a bunch of Tor relays and ridges too, which in my opinion should all get the BadExit / similar flag preventing them from being used at all. Tor code development also moves at a snails pace, we still don't have proper patches for circuit exhaustion attack, comparable to HTTP SlowLoris. I will hereby distance myself from the tor project completely, and not come back ever. Please get your shit together @TneTorProject. "Lisa"

1 1

Re: [tor-relays] Unsubscribing
by info＠backplanedns.org 27 Mar '21

27 Mar '21

In the spirit of cancel culture, I will be increasing my exit and guard relay traffic from 100mbps unthrottled pipes to 240. If we are to scrutinize the past actions of every great inventor, thinker, and innovator while disregarding achievements based on personal demerits then there would be no technological advancement. My belief in the mission and purpose still stands. It's about being apart of something bigger than myself or any specific individual regardless of opinion. THAT my friends, should be the consensus weight (pun intended). Dennis Emory Hannon Backplane LLC / BackplaneDNSSent from my T-Mobile 4G LTE device------ Original message------From: Volker MinkDate: Sat, Mar 27, 2021 10:33 AMTo: tor-relays(a)lists.torproject.org;Cc: Subject:Re: [tor-relays] UnsubscribingDont! :/ > Am 27.03.2021 um 15:29 schrieb Sebastian Urbach : > > Dear list, > > The last days on this list were stunning, to say the least. I'm going to unsubscribe today and i will decide tomorrow if i shut down all my relays. > -- > > Sincerely yours / M.f.G. / Sincères salutations > > Sebastian Urbach > > > _______________________________________________ > 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

1 0

0.4.6.1-alpha sure is noisy
by Scott Bennett 27 Mar '21

27 Mar '21

Here is the log from today from the heartbeat messages at 9 hours of uptime to the crash messages. Mar 26 16:46:35.356 [notice] Heartbeat: Tor's uptime is 9:00 hours, with 56 circuits open. I've sent 752.71 MB and received 753.05 MB. I've received 5067 connections on IPv4 and 0 on IPv6. I've made 3692 connections with IPv4 and 0 with IPv6. Mar 26 16:46:35.356 [notice] While bootstrapping, fetched this many bytes: 195778 (consensus network-status fetch); 1866820 (microdescriptor fetch) Mar 26 16:46:35.356 [notice] While not bootstrapping, fetched this many bytes: 7043780 (server descriptor fetch); 540 (server descriptor upload); 726053 (consensus network-status fetch); 100992 (microdescriptor fetch) Mar 26 16:46:35.357 [notice] Circuit handshake stats since last time: 20/20 TAP, 1650/1650 NTor. Mar 26 16:46:35.357 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 3 v3 connections; initiated 0 and received 384 v4 connections; initiated 3283 and received 4573 v5 connections. Mar 26 16:46:35.357 [notice] DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 1 single hop clients refused, 0 INTRODUCE2 rejected. Mar 26 16:47:49.441 [notice] Unable to find IPv6 address for ORPort 32323. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds] Mar 26 17:06:38.213 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.307 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.331 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.369 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.418 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.456 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.528 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.553 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.554 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.586 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.614 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.721 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.768 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.831 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.929 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:38.995 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.016 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.079 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.229 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.247 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.315 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.411 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.411 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.411 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.412 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.416 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.416 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.417 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.417 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.417 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.417 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.417 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.417 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:06:39.418 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.851 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.856 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.856 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.857 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.861 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.861 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.862 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.867 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.867 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.868 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.868 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.868 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.868 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.868 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.868 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.869 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.869 [warn] tor_bug_occurred_: Bug: src/feature/dircache/consdiffmgr.c:289: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.874 [warn] Bug: Tor 0.4.6.1-alpha: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at src/feature/dircache/consdiffmgr.c:289. Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.874 [warn] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.875 [warn] Bug: 0x1112469 <tor_bug_occurred_+0x1d9> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.875 [warn] Bug: 0x11bf665 <consdiffmgr_rescan+0xa25> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.875 [warn] Bug: 0x1c1baa8c1 <event_base_assert_ok_nolock_+0xa71> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.875 [warn] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.875 [warn] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.876 [warn] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:14:37.876 [warn] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 17:46:35.456 [notice] Heartbeat: Tor's uptime is 10:00 hours, with 54 circuits open. I've sent 805.66 MB and received 805.23 MB. I've received 5696 connections on IPv4 and 0 on IPv6. I've made 4176 connections with IPv4 and 0 with IPv6. Mar 26 17:46:35.457 [notice] While bootstrapping, fetched this many bytes: 195778 (consensus network-status fetch); 1866820 (microdescriptor fetch) Mar 26 17:46:35.457 [notice] While not bootstrapping, fetched this many bytes: 7615013 (server descriptor fetch); 540 (server descriptor upload); 806288 (consensus network-status fetch); 108133 (microdescriptor fetch) Mar 26 17:46:35.457 [notice] Circuit handshake stats since last time: 24/24 TAP, 1696/1696 NTor. Mar 26 17:46:35.458 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 3 v3 connections; initiated 0 and received 420 v4 connections; initiated 3732 and received 5165 v5 connections. Mar 26 17:46:35.458 [notice] DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 1 single hop clients refused, 0 INTRODUCE2 rejected. Mar 26 17:47:49.538 [notice] Unable to find IPv6 address for ORPort 32323. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds] Mar 26 18:10:36.902 [err] tor_assertion_failed_: Bug: src/feature/dirauth/voting_schedule.c:64: create_voting_schedule: Assertion end > start failed; aborting. (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.907 [err] Bug: Tor 0.4.6.1-alpha: Assertion end > start failed in create_voting_schedule at src/feature/dirauth/voting_schedule.c:64: . Stack trace: (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.907 [err] Bug: 0x1106ecc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.907 [err] Bug: 0x1112252 <tor_assertion_failed_+0x142> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.908 [err] Bug: 0x10e8541 <dirauth_sched_recalculate_timing+0x211> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.908 [err] Bug: 0x109b483 <networkstatus_set_current_consensus+0xeb3> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.908 [err] Bug: 0x11d8214 <connection_dir_reached_eof+0x1b74> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.908 [err] Bug: 0x11abc36 <connection_handle_read+0xbe6> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.908 [err] Bug: 0x108f430 <connection_add_impl+0x240> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.909 [err] Bug: 0x1c1baaa8a <event_base_assert_ok_nolock_+0xc3a> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.909 [err] Bug: 0x1c1ba5eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.909 [err] Bug: 0x109183a <do_main_loop+0x12a> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.909 [err] Bug: 0x108cc6c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) Mar 26 18:10:36.910 [err] Bug: 0x108b601 <tor_main+0x61> at /usr/local/bin/tor (on Tor 0.4.6.1-alpha ) While it was running, I rebuilt openssl with today's security update and then rebuilt tor. Some hours later the above crash occurred, so the restart should have the patched openssl library running now. I will let the list know if the crash reoccurs. BTW, a message I posted a couple of weeks ago got no responses, so I will ask the most important question again here. What are the new requirements for an HSDir flag? Before last fall, a minimum of 96 or 97 hours of uptime was the only requirements for a relay to be assigned the HSDir flag, but that is clearly not all that is necessary now. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

Conduct on this list
by Matthew Finkel 26 Mar '21

26 Mar '21

Please be aware that the Statement of Values [0] and Code of Conduct [1] apply on this mailing list (and all mailing lists provided by the Tor Project). This mailing list started accumulating racist slurs and other insults, which we have held in the moderation queue. Sending a mail containing racist epithets is absolutely not acceptable and will not be tolerated. Racism and sexism are not welcome in this community. Future transgressions will result in the sender being unsubscribed from the mailing lists and reported to the community council. Help us create an open, inclusive, and diverse community supporting Tor's mission. Thanks, Matthew/sysrqb on behalf of the list moderators [0] https://gitweb.torproject.org/community/policies.git/tree/statement_of_valu… [1] https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.t…

1 0

problem with new obfs4 bridge
by Christopher Sheats 26 Mar '21

26 Mar '21

Hello, We’re trying to get a 10GbE dual-stack public obfs4 bridge online, but presumably having some trouble with obfs4. I wished to open a bug, but my request for an account via https://gitlab.onionize.space/ is not being approved. These two recent tickets appear to be related: https://gitlab.torproject.org/tpo/core/tor/-/issues/40311 https://gitlab.torproject.org/tpo/core/tor/-/issues/40107 Ubuntu Server 20.10 tor 0.4.5.7 obfs4proxy 0.8 Firewall accepts TCP/UDP 80/443. Metrics link: https://metrics.torproject.org/rs.html#details/7ADC8C6BF93197830FDF3E06DFB4… torrc: BridgeRelay 1 ORPort 80 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:443 ExtORPort auto ContactInfo tech(a)emeraldonion.org Nickname EmeraldOnionBridge1 MaxMemInQueues 8192MB Log notice file /var/log/tor/notices.log Log notice syslog Tor Browser connect errors: “obfs4 [2620:18c:0:192::194]:443 7ADC8C6BF93197830FDF3E06DFB4D96E7CFEDCF3” 3/26/21, 18:46:55.269 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [2620:18c:0:192::194]:443 ID=H50HNwR2NkpCR9QPST8MdPfmTC43YyZ7sswt9yDTJGA RSA_ID=7ADC8C6BF93197830FDF3E06DFB4D96E7CFEDCF3 ("general SOCKS server failure") “obfs4 [2620:18c:0:192::194]:443” 3/26/21, 18:47:33.467 [WARN] Proxy Client: unable to connect OR connection (handshaking (proxy)) with [scrubbed] ("general SOCKS server failure") “[2620:18c:0:192::194]” 3/26/21, 19:03:52.905 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (TLS_ERROR; TLS_ERROR; count 2; recommendation warn; host 7ADC8C6BF93197830FDF3E06DFB4D96E7CFEDCF3 at 2620:18c:0:192::194:443) 3/26/21, 19:03:52.905 [WARN] 2 connections have failed: 3/26/21, 19:03:52.905 [WARN] 2 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE “23.129.64.194” 3/26/21, 19:06:43.811 [WARN] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 3; recommendation warn; host 0000000000000000000000000000000000000000 at 23.129.64.194:443) 3/26/21, 19:06:43.811 [WARN] 3 connections have failed: 3/26/21, 19:06:43.811 [WARN] 3 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE No issues: “[2620:18c:0:192::194]:80 7ADC8C6BF93197830FDF3E06DFB4D96E7CFEDCF3” “23.129.64.194:80 7ADC8C6BF93197830FDF3E06DFB4D96E7CFEDCF3” Notices log output: Mar 26 11:38:29.000 [notice] Tor 0.4.5.7 opening log file. Mar 26 11:38:29.600 [notice] We compiled with OpenSSL 1010106f: OpenSSL 1.1.1f 31 Mar 2020 and we are running with OpenSSL 1010106f: 1.1.1f. These two versions should be binary compatible. Mar 26 11:38:29.601 [notice] Tor 0.4.5.7 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1f, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.4.5 and Glibc 2.32 as libc. Mar 26 11:38:29.601 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Mar 26 11:38:29.601 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Mar 26 11:38:29.601 [notice] Read configuration file "/etc/tor/torrc". Mar 26 11:38:29.603 [notice] Opening Socks listener on 127.0.0.1:9050 Mar 26 11:38:29.603 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050 Mar 26 11:38:29.603 [notice] Opening OR listener on 0.0.0.0:80 Mar 26 11:38:29.603 [notice] Opened OR listener connection (ready) on 0.0.0.0:80 Mar 26 11:38:29.603 [notice] Opening OR listener on [::]:80 Mar 26 11:38:29.603 [notice] Opened OR listener connection (ready) on [::]:80 Mar 26 11:38:29.603 [notice] Opening Extended OR listener on 127.0.0.1:0 Mar 26 11:38:29.603 [notice] Extended OR listener listening on port 40739. Mar 26 11:38:29.603 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:40739 Mar 26 11:38:30.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Mar 26 11:38:30.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Mar 26 11:38:30.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. Mar 26 11:38:30.000 [notice] Your Tor server's identity key fingerprint is 'EmeraldOnionBridge1 7ADC8C6BF93197830FDF3E06DFB4D96E7CFEDCF3' Mar 26 11:38:30.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'EmeraldOnionBridge1 09E23FA5AD9CF64DBEFE88A39A2F1EB215E44B53' Mar 26 11:38:30.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'EmeraldOnionBridge1 H50HNwR2NkpCR9QPST8MdPfmTC43YyZ7sswt9yDTJGA' Mar 26 11:38:30.000 [notice] Bootstrapped 0% (starting): Starting Mar 26 11:38:36.000 [notice] Starting with guard context "default" Mar 26 11:38:36.000 [notice] Signaled readiness to systemd Mar 26 11:38:36.000 [notice] Registered server transport 'obfs4' at '[::]:443' Mar 26 11:38:37.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Mar 26 11:38:37.000 [notice] Opening Socks listener on /run/tor/socks Mar 26 11:38:37.000 [notice] Opened Socks listener connection (ready) on /run/tor/socks Mar 26 11:38:37.000 [notice] Opening Control listener on /run/tor/control Mar 26 11:38:37.000 [notice] Opened Control listener connection (ready) on /run/tor/control Mar 26 11:38:37.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Mar 26 11:38:37.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Mar 26 11:38:37.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Mar 26 11:38:37.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Mar 26 11:38:37.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Mar 26 11:38:37.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Mar 26 11:38:38.000 [notice] Bootstrapped 100% (done): Done Mar 26 11:38:38.000 [notice] Now checking whether IPv4 ORPort 23.129.64.194:80 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Mar 26 11:38:38.000 [notice] Now checking whether IPv6 ORPort [2620:18c:0:192::194]:80 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Mar 26 11:38:39.000 [notice] Self-testing indicates your ORPort [2620:18c:0:192::194]:80 is reachable from the outside. Excellent. Mar 26 11:38:39.000 [notice] Self-testing indicates your ORPort 23.129.64.194:80 is reachable from the outside. Excellent. Publishing server descriptor. Mar 26 11:40:32.000 [notice] Performing bandwidth self-test...done. A prior torrc config set the IPs explicitly, but had the same result: ServerTransportListenAddr obfs4 23.129.64.194:443 ServerTransportListenAddr obfs4 [2620:18c:0:192::194]:443 I can provide debug logs as necessary. Possibly of note, our firewall does not use connection tracking and applies the same rules as our exit relays which use the same ports. Pro-active note: The bridge shares the same 23.129.64.0/24 subnet as Emerald Onion's Tor exit relays, so there is no risk of a user entering and exiting our physical network (see "2.2. Path selection and constraints"): https://github.com/torproject/torspec/blob/master/path-spec.txt Cheers, -- Christopher Sheats Executive Director for Emerald Onion Email: yawnbox(a)emeraldonion.org Phone: +1 206-739-3390 Web: https://emeraldonion.org/

1 0

Tor project helping to attempt to cancel Richard Stallman
by Jeffrey Cliff 26 Mar '21

26 Mar '21

I've been running a relay/exit node for many years. Tor user since ~2004. To the extent that my voice means anything at all here, I would like to strongly condemn the Tor project joining the attempt to cancel Richard Stallman. Stallman represents software freedom to me generally and as of today I will be shutting down my exit node in protest of this action by the Tor Project. I hope the rest of you out there, who depend every day on GNU project code which would not exist without RMS's project, might consider joining me. Jeff Cliff former tor exit node admin

19 25

Active MetricsPort logs "Address already in use"
by Alexander Dietrich 25 Mar '21

25 Mar '21

Hello, when I activate the "MetricsPort" feature, the Tor log reports that it is going to open the port, then it says "Address already in use". According to "netstat", the address is indeed in use, but by "tor". Sending GET requests to the address returns empty responses. Any ideas? Kind regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

2 4

Tor 0.4.5.6 and missing IPv6
by Marco Predicatori 25 Mar '21

25 Mar '21

Hi, I've recently upgraded to Tor 0.4.5.6. Everything seems to work fine, but in the notices_log file I have a lot of these lines: [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address. I don't have IPv6, and any line mentioning IPv6 in the torrc file is commented. Is there anythng I need to do in order to get rid of those notices, or can I just let them be? Thanks, Marco -- https://metrics.torproject.org/rs.html#details/A4E74410D83705EEFF24BC265DE2…

4 10

Security advisory: Please upgrade to today's OpenSSL.
by Nick Mathewson 25 Mar '21

25 Mar '21

Hi, all! There is a new version of OpenSSL out today, with a security advisory that affects Tor. The vulnerability is CVE-2021-3449, as described on https://www.openssl.org/news/secadv/20210325.txt . It affects OpenSSL versions 1.1.1 through 1.1.1j. OpenSSL 1.1.1k is the first version with a fix. I haven't tested this bug, but I believe that it would allow an adversary to remotely crash Tor relays and authorities. It won't have any effect on Tor clients. I suggest that everybody should upgrade to the latest OpenSSL when it becomes available on their platform. best wishes, -- Nick

1 0

Failed upgrade
by r1610091651 24 Mar '21

24 Mar '21

Hi FYI So I've upgraded tor package from 0.4.4.6 to 0.4.5.7-1~xenial+1. No other changes. Yet on startup tor is complaining about mis-configuration: Mar 23 20:55:02.928 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Mar 23 20:55:02.929 [notice] Read configuration file "/etc/tor/torrc". Mar 23 20:55:02.932 [warn] Configuration port ORPort 9443 superseded by ORPort <local-ip>:9443 Mar 23 20:55:02.932 [warn] We are listening on an ORPort, but not advertising any ORPorts. This will keep us from building a router descriptor, and make us impossible to use. Mar 23 20:55:02.932 [warn] Failed to parse/validate config: Misconfigured server ports Mar 23 20:55:02.932 [err] Reading config failed--see warnings above. config: ORPort <local-ip>:9443 NoAdvertise ORPort 9443 NoListen IPv4Only AddressDisableIPv6 1 OutboundBindAddress <local-ip> This config is according to spec and worked with 4.4.6. Seems to be related to thes issues, except for me it's blocking: tor fails to start. https://gitlab.torproject.org/tpo/core/tor/-/issues/40300 https://gitlab.torproject.org/tpo/core/tor/-/issues/40302 I had to add 0.0.0.0 as ip to make tor start, although that's not documented... ORPort <local-ip>:9443 NoAdvertise ORPort 0.0.0.0:9443 NoListen IPv4Only Regards

2 1

is this valid bridge config
by gi vian 23 Mar '21

23 Mar '21

hello, i want to run bridge. i have configured using tor relay configurator(1). is this valid or can it be improved. config ------ ORPort auto SocksPort 0 BridgeRelay 1 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:8042 ExtOrPort auto Log notice file /var/log/tor/notices.log ExitPolicy reject *:* ------ regards, vian (1) https://tor-relay.co/

2 1

Circuit Creation Madness: Anyone else still experiencing (extremely) excessive clients / (possibly) modified relays creating millions upon millions of circuits?
by William Kane 23 Mar '21

23 Mar '21

@tor-relays: Sorry for being quite noisy recently but I really need to know how many people are suffering from the same madness I am encountering right now. Quick excerpt from the log: ... Mar 22 09:48:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:48:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [12420 similar message(s) suppressed in last 120 seconds] Mar 22 09:49:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:49:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [31764 similar message(s) suppressed in last 60 seconds] Mar 22 09:50:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:50:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [104748 similar message(s) suppressed in last 60 seconds] Mar 22 09:51:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:51:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [364165 similar message(s) suppressed in last 60 seconds] Mar 22 09:52:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:52:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [509474 similar message(s) suppressed in last 60 seconds] Mar 22 09:53:10 <hostname_redacted> tor[pid_redacted]: Mar 22 09:53:10.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [241332 similar message(s) suppressed in last 60 seconds] ... This then goes on for a while, stopping at a few million suppressed messages / circuit creation attempts. Sorry, but 1 million circuit creation requests in just 5 minutes, there is no way that this is legitimate behavior we are seeing - this is also what was previously used to get my relay oom-killed but that I have fixed so the legitimate clients hopefully don't suffer too much anymore. If any other relay operators are encountering the same log entries or behavior, please don't hesitate to reply. Added tor-dev(a)lists.torproject.org as a CC as they might want to know about this. @tor-dev: I suspect some kind of denial-of-service attack against onion services or a more targeted attack against singular relays for guard discovery / traffic confirmation attacks. Might be smart to add some code which, if this scenario is triggered, lists offenders by hashes of their signing keys (if relay), or IP addresses (if client). There doesn't seem to be a defense against this, and the new connect() rate-limit added through ticket 40253 also won't handle this as the connection is already ACK'd and established, and a malicious relay with custom source code could do whatever it was programmed to do anyway. - William

2 2

ECONNREFUSED
by tor 23 Mar '21

23 Mar '21

Hi All, I've been running a bridge on my home lan. I'm able to successfully attach to the bridge on the lan and from the wan. There are established circuits and clients: https://metrics.torproject.org/rs.html#details/E120A0492F789F5367EAD84C64F9… According to the tcp reachablilty test everything is reachable. However, the status page keeps saying I'm dysfunctional with a ECONNREFUSED: https://bridges.torproject.org/status?id=E120A0492F789F5367EAD84C64F92EE279… So everything seems to be working on my end. -matt

3 2

Question
by Андрей Гвоздев 23 Mar '21

23 Mar '21

What does it mean "Tor's file descriptor usage is at 90%. If you run out Tor will be unable to continue functioning."?

2 1

Questing regarding Team Cymru Tor Relays and Bridges
by Lisa Winter 23 Mar '21

23 Mar '21

Hello list, I just visited BridgeDB and got a bridge from "Team Cymru", according to the whois of the IP - should the Tor Project really allow a company trying to "track and take down threat actors and criminals around the globe" host a substantial portion of the network, according to their info page: https://team-cymru.com/company/ The following was also very concerning: "Team Cymru is comprised of former…" - ... - Law enforcement - ISP backbone engineers - ... I suspect that they log connections to their relays and bridges, and maybe even more. Such companies profit from gathering and selling information's, exploits and the likes. bad-relays rejected this message, which is concerning.. I hope someone here could redirect it to the right people, or do the Tor Project higher-ups know the people behind Team Cymru and vouch for them? Bye, Lisa Winter

3 3

Sunsetting C3WLittleGem and C3WPhantomStreak
by MacLemon 18 Mar '21

18 Mar '21

Hi! FYI: We sadly have to sunset two of our relays due to persistent network/upling problems with the vSphere cluster of our hosting provider. It wasn't possible to solve these issues in about a year. To reduce our volunteers' time investment for no gain, we'll turn of C3WLittleGem and C3WPhantomStreak in the next few days. If you want to have a last look at them, here's a link to our family. https://metrics.torproject.org/rs.html#search/family:B1F09810C4F7B9D30F483D… We'll continue running C3WEyeOfSauron and hope being able to add more relays again in the future. Best regards MacLemon (on behalf of Chaos Computer Club Wien (C3W))

2 1

Re: [tor-relays] Did 'Sandbox 1' break Tor for anyone else on 0.4.5.6?
by William Kane 17 Mar '21

17 Mar '21

Hi Peter, >Would be great if you could get details about the failing call. I already thought of gathering said details by tracing the process, but did not want to risk my uptime statistics, which would inevitably happen if I had to restart the server and service over and over (I disabled tracing globally through the Yama LSM as a security measure, i.e. kernel.yama.ptrace_scope == 3) - recently I lost the guard flag multiple times, caused by some sort of attack that I already reported on this list (tor-relays) - someone kept creating a fuckton of circuits through my relay (averaging 90k per minute), thus causing tor to run out of memory / get oom-killed by the kernel before it could even step in and close the circuits - if it was even trying to, it would make sense for the DoS mitigation code to be active only for the first link in the circuit aka the guard, and my node simply being a middle-only relay, it got completely stomped by said attack. After somewhat mitigating this attack by tweaking MaxMemInQueues, creating a bigger swap file and tuning vm.swappiness, I regained the guard flag, but then the hypervisor my KVM box is running under experienced some issues and had to be rebooted - once again, I received no notice of that until the relay was already offline for a few days, causing me to lose the guard flag again. Seems like luck is just not on my side these days, or well, it's been weeks now. > You should simply see a Permission Denied if the capability is the problem. Here's a copy from stdout, only happening if Sandbox is set to 1.: Mar 15 20:15: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. Mar 15 20:15:21.000 [warn] fstat() on directory /var/lib/tor_debug failed. Mar 15 20:15:21.000 [err] Can't create/check datadirectory /var/lib/tor_debug Mar 15 20:15:21.000 [err] Error initializing keys; exiting Running it as a privileged user does not change thing, so no permissions issue: Mar 15 20:17:24.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. Mar 15 20:17:24.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Mar 15 20:17:25.000 [warn] fstat() on directory /var/lib/tor_debug failed. Mar 15 20:17:25.000 [err] Can't create/check datadirectory /var/lib/tor_debug Mar 15 20:17:25.000 [err] Error initializing keys; exiting I've traced down the origin of the fstat() call to this piece of code: https://github.com/torproject/tor/blob/master/src/lib/fs/dir.c#L158 However, looking at the code that establishes and populates seccomp rules, it seems like fstat and it's 64 bit counterpart are not subject to (parameter) filtering, i.e. seccomp_rule_add_0 is invoked with the parameter SCMP_ACT_ALLOW, reading the manpage for seccomp_rule_add(3) reveals: "The seccomp filter will have no effect on the thread calling the syscall if it matches the filter rule." References: https://github.com/torproject/tor/blob/master/src/lib/sandbox/sandbox.c#L148 https://github.com/torproject/tor/blob/master/src/lib/sandbox/sandbox.c#L15… https://man7.org/linux/man-pages/man3/seccomp_rule_add.3.html So, even though technically, seccomp should allow these syscalls to be invoked, no matter which parameters are passed, somehow enabling the whole sandbox subsystem still breaks fstat. We are getting into tor-dev@ territory here, so maybe someone who is more experienced with the code base could figure out why this is happening, I'm pretty good at C/C++ on Linux / Windows and all the shenanigans that come with it, but lack time to debug this further. I've added tor-dev(a)lists.torproject.org as a CC just in case. - William 2021-03-15 17:10 GMT, Peter Gerber <tor(a)arbitrary.ch>: > Hi William > > William Kane: >> Hi everyone, >> >> Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in >> seccomp sandbox completely breaks tor, i.e. it gets killed by the >> kernel on start for a seccomp violation (fstat(..)) - sandboxing >> worked fine on 0.4.4.6, my system configuration did not change between >> the updates. > > Tor itself usually fails with a Permission Denied error when a syscall > fails due to seccomp. So, this is rather odd. > >> I figured this was happening because I do not grant the >> CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's >> the reason. > > You should simply see a Permission Denied if the capability is the problem. > > Would be great if you could get details about the failing call. If > seccomp is involved, you should be able to get details like this: > > • install package auditd > • make sure auditd is running > • crash Tor > • find the syscall with `ausearch -ts recent -i` > > Peter >

2 2

Did 'Sandbox 1' break Tor for anyone else on 0.4.5.6?
by William Kane 16 Mar '21

16 Mar '21

Hi everyone, Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in seccomp sandbox completely breaks tor, i.e. it gets killed by the kernel on start for a seccomp violation (fstat(..)) - sandboxing worked fine on 0.4.4.6, my system configuration did not change between the updates. Not specifying 'Sandbox 1' in the torrc allows tor to fully start as usual, I had to disable it post-update in order to be able to continue running my relay. /etc/tor/torrc: ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 Nickname michaelscott ContactInfo ttallink(a)googlemail.com ControlPort 9051 SocksPort 0 CookieAuthentication 1 ExitPolicy reject *:* DataDirectory /var/lib/tor # Sandbox 1 ShutdownWaitLength 120 MaxMemInQueues 672MB /usr/lib/systemd/system/tor.service: [Unit] Description=Anonymizing Overlay Network After=network.target [Service] User=tor Type=simple ExecStart=/usr/bin/tor -f /etc/tor/torrc ExecReload=/usr/bin/kill -HUP $MAINPID KillSignal=SIGINT LimitNOFILE=32768 PrivateDevices=yes [Install] WantedBy=multi-user.target /etc/systemd/system/tor.service.d/override.conf: [Service] PrivateTmp=yes ProtectHome=yes ProtectSystem=strict ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectControlGroups=yes NoNewPrivileges=yes RestrictSUIDSGID=yes RestrictAddressFamilies=AF_INET AF_INET6 ReadWritePaths=/var/lib/tor CapabilityBoundingSet=CAP_NET_BIND_SERVICE TimeoutStopSec=2min 15s I'm running ArchLinux with the 5.11.4 kernel, Tor is still sandboxed by systemd so this is not a huge issue but I would like to be able to continue using the built-in sandbox as well as systemd's sandboxing options in order to maximize process isolation. Did anyone else run into this? I would have posted a bug report but due to various reason I am not able to do so right now. I figured this was happening because I do not grant the CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's the reason. Any help is greatly appreciated. - William

2 1

Re: [tor-relays] I was banned from PayPal
by potlatch 13 Mar '21

13 Mar '21

Hello kantorkel and Tor ops, To put a little meat on the bone of this situation, I did not receive an email from PayPal--I was informed that I was banned when I tried to make a payment for VPS hosting. During the week before this ban, I had sent funds to both Flokinet for an exit relay in Finland and to ITLDC.com for VPS hosting in Poland--both exit relays. I used the PayPal support email to ask for the reason I was banned and to ask for re-instatement. I have heard nothing back. I had surmised that someone was monitoring payments to off-shore hosting companies and maybe they assumed I was supporting a news agency--I don't know really. If that is the case, why haven't the hosting sites been banned as well? The message in my PayPal account referred to a violation of the user agreement. Here is the full text of the message: -We're unable to continue offering our services -Thank you for using PayPal as your payment partner. -Unfortunately, we are unable to continue offering our services -to you at this time due to the nature of your business and/or -activity in your account and the risk it poses to PayPal. This -decision can't be overturned. -If you owe refunds to any of your buyers, you can use the money -in your PayPal account to refund them. -Money in your PayPal account will be held for 180 days. After -180 days, we'll email you information on how to withdraw your -money. The only transactions on this account over the past 3-months were VPS lease payments off-shore. I looked up the user agreement to determine where I had violated the rules and found only a single reference to operating servers: -Service Requiring Pre-Approval: -Providing file sharing services or access to newsgroups; or -selling alcoholic beverages, non-cigarette tobacco products, --e-cigarettes or prescription drugs/devices. I have a zoom meeting with two attorneys from EFF.org on March 18. Stay tuned....and maybe ban PayPal. --potlatch Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, March 11, 2021 12:06 AM, Matthias Marx <kantorkel(a)hamburg.freifunk.net> wrote: > Hi Potlatch, > > would you mind sharing PayPal's email / full message with me? > > Regards from Hamburg > kantorkel > > Am 3/11/21 um 12:42 AM schrieb potlatch: > > > Today I received a message from PayPal that paying for Tor relay server leases was a direct violation of my usage agreement. I have been paying off-shore VPS hosts for my Tor server leases with PayPal for at least ten years. Very interesting that they act now. > > They specifically state the ban was for: > > Providing file sharing services or access to newsgroups; or selling alcoholic beverages, non-cigarette tobacco products, e-cigarettes or prescription drugs/devices. > > They further state that the ban is permanent and not reversible. > > I liked using PayPal because it was a safe way to pay and didn't expose my credit card information. Before PayPal I used a prepaid card which I will probably go back too. > > --Potlatch > > Sent with ProtonMail https://protonmail.com Secure Email. > > > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

Fallback EOL
by Anders Burmeister 13 Mar '21

13 Mar '21

We lost Fallback relay 775B0FAFDE71AADC23FFC8782B7BEB1D5A92733E Had it’s EOL due to a major incident in data center. We are all sorry Regards /anders

1 0

I was banned from PayPal
by potlatch 12 Mar '21

12 Mar '21

Today I received a message from PayPal that paying for Tor relay server leases was a direct violation of my usage agreement. I have been paying off-shore VPS hosts for my Tor server leases with PayPal for at least ten years. Very interesting that they act now. They specifically state the ban was for: Providing file sharing services or access to newsgroups; or selling alcoholic beverages, non-cigarette tobacco products, e-cigarettes or prescription drugs/devices. They further state that the ban is permanent and not reversible. I liked using PayPal because it was a safe way to pay and didn't expose my credit card information. Before PayPal I used a prepaid card which I will probably go back too. --Potlatch Sent with [ProtonMail](https://protonmail.com) Secure Email.

10 9

Thoughts and insight before bridge moving
by a tor op 09 Mar '21

09 Mar '21

Hello I was thinking of perhaps asking and checking if the list has some comments on thoughts I have. I'm attaching a picture, hope that's not a problem, guess it's better than providing a URL to a file upload place (or maybe that's ok too?). I've been running a TOR bridge node for some years and need to rebuild/move it. For some time I wasn't sure how useful it was, whether or not it contributed in a useful way and I don't think it still has all the flags it could/should have? So, for you around here with an even deeper experience of the network, looking at the stats, are there any particular insights that can be drawn from there? Is it a useful bridge, stats that could or should look differently, anything else? BTW, there's a huge spike in connections on 9 Aug -20 (and there's been similar occasions earlier too) does that coincide with known attacks on the network or what? I guess, should I want to continue providing service, that it's useful or possibly preferred to move over the keys/config (?) to indicate same admin (and for users if there's no noticeable interruption the move won't even be noticed I suppose). TIA, a tor op

4 4

Bridge operator iat_mode setting
by torjoy 04 Mar '21

04 Mar '21

Hi All, I work with time and frequency references and run some tor bridges. What is the objective of "iat_mode" setting? Is an good timming reference important for this setting? For now, i'm adminstrating 3 briges, one with iat_mode=0, iat_mode=1 and iat_mode=2. Could you explain or forward me to some reading about it? Best regards, Luiz Sent with [ProtonMail](https://protonmail.com) Secure Email.

9 14

difficulty installing
by potlatch 03 Mar '21

03 Mar '21

I've been deploying Tor nodes for over a decade--maybe several dozen or more. I still have ten nodes operating in six developing or smaller countries. Many are exits. Recently, I leased a VPS in a Eastern European country with permission to use it as an exit relay. This brought back some bad memories of a year ago when I last tried to make the Tor software function. The problems then are the problems I have now. I'm disappointed by the state of the installation packages and documentation these days (since a year ago at least). Tor won't start after the initialization message. But it displays 'If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility'. Where the hell is the Exit Relay option? Then there is the issue of not being able to acquire the Tor keys or for the VPS to find the key-ring. Another message: 'The repository '[https://deb.torproject.org/torproject.org](https://ded.torproject.org/torpr… stretch InRelease' is not signed. Data from such a repository can't be authenticated and is therefore potentially dangerous to use.' So, is it just that the documentation is messed up or has everyone given up on the Tor project? Nyx has never completely worked for me. Never with a local config file. I think there are some python utilities that need to be installed to make it work. I never asked but no one ever offered. The documentation is silent regarding this point. The old ARM software would give me an idea of how many file descriptors I was using and if I had provided enough. Arm also filled in the users list with column information instead of providing mostly ????. I donate regularly to Tor, EFF and Riseup. It's what I believe in. Does Tor need some volunteer help? I can only code python--would that help? potlatch in WA State Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

IPv6 auto-discovery vs. privacy extensions
by Onion Operator 01 Mar '21

01 Mar '21

Saluton, My relay started to log this message since 0.4.5.5: Auto-discovered IPv6 address [...]:443 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] I think it started with the introduction of IPv6 auto-discovery. The problem, as I understand it, is that my relay has IPv6 privacy extensions enabled and therefore the IPv6 detection logic gets fooled. Indeed the IPv6 I see in the logs is one of the temporary addresses used as client towards other relays. Relevant config is: ORPort 443 IPv4Only ORPort [...]:443 IPv6Only I added the IPv{4,6}Only options only in searching a solution to this problem, before 0.4.5.5 the IPv6 relay worked perfectly without. In reading the documentation of AddressDisableIPv6 I got the impression that if (any?) ORPort is configured with IPv4Only the IPv6 auto-discovery gets disabled but evidence does not support my understanding. Is it a bug? Any other way to disable IPv6 auto-discovery? -- flev

4 4