- tor-relays - lists.torproject.org

User advisory to check for xz-utils backdoor
by pasture_clubbed242＠simplelogin.com 02 Apr '24

02 Apr '24

Greetings, I do not normally use mailing lists such as this one to inform subscribers of security notices, but this issue is extreme enough where it may benefit the anonymity of Tor users if relay operators are aware of it sooner. The near-universally used 'xz' compression library has been found to contain a backdoor in certain code branches. This backdoor has made it into some systems such as Debian Sid. Details regarding this backdoor are available here. https://www.openwall.com/lists/oss-security/2024/03/29/4 It is suspected that if your OpenSSH server links to the xz library, which Debian appears to do so, then this backdoor is remotely exploitable. If your OpenSSH server does not link to this library, then your system still contains many processes that run xz actions as the root user, some input of which may be less than trusted. For those needing a patch, I recommend you research your distribution's security advisory page for further information. References: Debian Sid Advisory: https://security-tracker.debian.org/tracker/CVE-2024-3094

2 1

Backdoor in upstream xz/liblzma leading to ssh server compromise
by hello＠relaymagic.org 02 Apr '24

02 Apr '24

Just wanted to bring this to everyone’s attention if you hadn’t seen it already. Developer discovered a backdoor in xz-utils https://www.openwall.com/lists/oss-security/2024/03/29/4 -- Sent from Canary (https://canarymail.io)

2 1

Tor relay operator research
by Ana Custura 29 Mar '24

29 Mar '24

Dear operators, We're conducting a study to understand relay operator motivations and needs, funded by OTF. We've already interviewed several of you and got feedback relating to community matters. Based on that feedback, we've put together a comprehensive survey: English: https://survey.torproject.org/index.php/751125?lang=en Spanish: https://survey.torproject.org/index.php/751125?lang=es If you have about 30 minutes to spare and fill this in, it would be much appreciated! Your responses are valuable and will be used by the Tor project to understand the needs of the community, and how you feel about some controversial Tor-related issues. The survey is anonymous. Cheers Ana PS: to find out more about the project, see https://www.opentech.fund/projects-we-support/supported-projects/the-tor-pr…

1 0

Announcement: Tor-Weather 2.0 Release
by Sarthik Gupta 27 Mar '24

27 Mar '24

Dear Tor-Relay Community, I hope this email finds you well. I am excited to announce the release of Tor-Weather 2.0, a significant rewrite of our Tor-Weather service. This release was primarily focused on refactoring the codebase, resulting in extensive changes. This initiative not only enhances the existing codebase but also accelerates the development of new features and addresses numerous bugs in the current service. Some of the key highlights of Tor-Weather 2.0 include: 1. Support for bridges: We have added support for tracking bridges. Creating subscriptions for bridges works the same way as creating those for relays. 2. Improved email templates: Emails have been completely revamped & will now offer both html & txt based mime-types. No more incorrectly spaced emails. 3. Added additional details in emails: We've added additional details to the emails. This includes, link to the relay's metric page, additional context for the subscription, etc. 4. Improved reliability & bug-fixes: The new deployment process should greatly improve the availability & reliability of the service. This also includes bunch of bug-fixes across the application. We believe that these updates will greatly benefit the Tor-Relay community and contribute to a more streamlined and efficient relay management experience. To start using Tor-Weather 2.0, simply visit [Tor-Weather](https://weather.torproject.org/login) and log in with your existing credentials. If you encounter any issues, please file a ticket in our [bug tracker](https://gitlab.torproject.org/tpo/network-health/tor-weather/-/iss…. Thank you for your continued support and participation in the Tor-Relay community. We look forward to hearing your thoughts on Tor-Weather 2.0 and continuing to improve our services to better serve your needs. Best regards, Sarthik Gupta & Network-Health Team

1 0

Re: [tor-relays] Request for Feedback on Relay Node Update Management
by denny.obreham＠a-n-o-n-y-m-e.net 26 Mar '24

26 Mar '24

Relays do restart for different reasons. For example, two of my relays (the upgrade process is automated on both) were restarted on March 23rd, practically at the same time. Different OS versions on different machines from different ISP for both relays. One was restarted because some libraries needed to be upgraded on the system: ``` The following packages will be upgraded: libbsd0 libc-bin libc6 libxslt1.1 locales 5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [...] Restarting services... [...] tor(a)default.service [...] ``` The server even needed to be rebooted afterward. The other one had a very different reason, as you can see from the syslog: ``` Mar 23 03:07:43 leslie kernel: [849147.801728] Out of memory: Killed process 930 (tor) total-vm:850180kB, anon-rss:620800kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:1652kB oom_score_adj:0 Mar 23 03:07:43 leslie systemd[1]: tor(a)Leslie.service: A process of this unit has been killed by the OOM killer. Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Main process exited, code=killed, status=9/KILL Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Failed with result 'oom-kill'. Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Consumed 2d 5h 54min 39.122s CPU time. Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Scheduled restart job, restart counter is at 1. Mar 23 03:07:44 leslie systemd[1]: Stopped Anonymizing overlay network for TCP (instance Leslie). Mar 23 03:07:44 leslie systemd[1]: tor(a)Leslie.service: Consumed 2d 5h 54min 39.122s CPU time. Mar 23 03:07:44 leslie systemd[1]: Starting Anonymizing overlay network for TCP (instance Leslie)... ``` That was the last time both relays were restarted (~ 3 days ago) Denny On 03/26/2024 04:54 AM Alessandro Greco via tor-relays wrote .. Dear Tor-Relays Mailing List Members, I hope this email finds you well. I'm reaching out to share some observations and pose some questions regarding the management of relay node updates, particularly concerning their impact on stability and security of the service provided. Recently, I've noticed an interesting pattern with my relay node (ID: 47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed TorProject's recommendations [2] and configured automatic updates, which has led to frequent restarts of the node to keep the Tor software up-to-date. While this practice ensures high security by keeping the software updated, it seems to compromise the stability of the node itself. The Uptime value of my node has remained at a maximum of a few hours. This situation has prompted me to reflect on what might be the best strategy to adopt. On one hand, frequent updates ensure optimal security, while on the other hand, continuous restarts may affect the user experience for those relying on the node's stability for their Tor activities. As such, I'd like to pose some questions to the community to gather feedback and assess best practices: 1. In your opinion, is it preferable to maintain automatic updates to ensure maximum security, even if frequent restarts may compromise the node's stability? 2. Or would it be more sensible to adjust the update frequency, perhaps performing them once or twice a week, to ensure greater stability of the node without excessively compromising security? 3. Have you had similar experiences with your relay nodes? How have you addressed this challenge and what were the outcomes? Thank you in advance for your time and cooperation. Best regards, Aleff. [1] https://metrics.torproject.org/rs.html#details/47B72187844C00AA5D524 415E52E3BE81E63056B [2] https://community.torproject.org/relay/setup/guard/debian-ubuntu/upd ates/ --- Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)

1 0

GeoIPFile option warning
by krishna e bera 25 Mar '24

25 Mar '24

I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading.

2 1

Tor is not upgrading via apt from deb.torproject.org
by s7r 23 Mar '24

23 Mar '24

Hello all, I have recently found something interesting on my relays. On all relays and clients actually. As always I am using Debian and apt to get Tor from deb.torproject.org tor-nightly-main-bullseye main (for example). I also have the keyring installed, proper key and everything. Currently I am on: Tor version 0.4.9.0-alpha-dev. This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html) Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1w, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc. Tor compiled with GCC version 10.2.1 Since October 2023. If I manually check out deb.torproject.org with my browser I see there is another package released in February 2024, except it notes as the same version 4.9.0-alpha-dev but it has a different timestamp. $ apt update reports no errors, looks like is working fine, but it doesn't notify there's a newer version and does not apply any updates to Tor. This happens only to Tor package from nightly, rest of packages from debian.org deb are updated as usual. So, anyone else experienced this? Do I need to configure apt in a different way than we used to do? I maintain this style of setup for Tor since Debian 7 :-), any changes needed? Thank you! -s7r

5 8

Problem with relay and ovh??
by Keifer Bly 07 Mar '24

07 Mar '24

Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… Goes offline at sporadic times. Upon checking the tor log file, there does not appear to be anything written causing tor to crash: Feb 18 00:36:34.000 [notice] Tor 0.4.8.10 opening new log file. Feb 18 00:36:34.630 [notice] We compiled with OpenSSL 101010ef: OpenSSL 1.1.1n 15 Mar 2022 and we are running with OpenSSL 101010ef: 1.1.1n. These two versions should be binary compatible. Feb 18 00:36:34.634 [notice] Tor 0.4.8.10 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Feb 18 00:36:34.634 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Feb 18 00:36:34.636 [notice] Read configuration file "/etc/tor/torrc". Feb 18 00:36:34.637 [notice] Based on detected system memory, MaxMemInQueues is set to 1462 MB. You can override this by setting MaxMemInQueues by hand. Feb 18 00:36:34.640 [notice] Opening OR listener on 0.0.0.0:9001 Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001 Feb 18 00:36:34.640 [notice] Opening OR listener on [::]:9001 Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on [::]:9001 Feb 18 00:36:34.640 [notice] Opening Directory listener on 0.0.0.0:9030 Feb 18 00:36:34.640 [notice] Opened Directory listener connection (ready) on 0.0.0.0:9030 Feb 18 00:36:35.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Feb 18 00:36:35.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Feb 18 00:36:35.000 [notice] Your Tor server's identity key fingerprint is 'udeserveprivacy 79E3B585803DE805CCBC00C1EF36B1E74372861D' Feb 18 00:36:35.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'udeserveprivacy b7n+DkH5IsJHJexEqilhQ5tC0LRd9Td888RZpYkxEvc' Feb 18 00:36:35.000 [notice] Bootstrapped 0% (starting): Starting Feb 18 00:36:49.000 [notice] Starting with guard context "default" Feb 18 00:36:50.000 [notice] Unable to find IPv6 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. Feb 18 00:36:50.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Feb 18 00:36:50.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Unless the old file is being overwritten when tor restarts. But is there a known problem with OVH that causes this? Thanks. Oddly there is no definite time when this happens, sometimes the relay operates no problem for weeks on end and then it happens, other times it only makes it a day or two. --Keifer

3 4

Next Tor Relay Operator Meetup - March 2nd, 2024 @ 19.00 UTC
by gus 05 Mar '24

05 Mar '24

Hello Tor Relay operators, Please save the date! The next Tor Relay Operator Meetup will happen on Saturday, March 2nd at 2024 at 19.00 UTC. We're still working on the agenda for this meetup, however feel free to add your topics directly to the ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/86 Meetup details - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: March 2nd, 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. best, Gus -- The Tor Project Community Team Lead

1 3

Worse throughput with 0.4.8.x, on a slow CPU
by Roman Mamedov 04 Mar '24

04 Mar '24

Hello, Ater upgrading from Tor 0.4.7.13 to 0.4.8.9, I get a much worse bandwidth numbers. The CPU is Atom C2338 with two cores at 1.75 Ghz. Multiple Tor instances are running to take advantage of both cores. On the older version it gets about 80+80 Mbit total in+out. On the new one the average is at most 45+45 Mbit. There are frequent periods where the bandwidth drops to 5-10 Mbit for 3-5 seconds, while all Tor processes continue to use 100% of both CPUs, then gradually climbs back up. Does anyone notice anything similar? Here's how it looks for a few days on 0.4.8 then a roll-back: ------------------------+-------------+-------------+--------------- today 461.94 GiB | 470.84 GiB | 932.78 GiB | 153.98 Mbit/s ######################################## 12/12/23 462.81 GiB | 475.67 GiB | 938.48 GiB | 91.12 Mbit/s ####################### 12/11/23 434.72 GiB | 443.08 GiB | 877.80 GiB | 85.23 Mbit/s ###################### 12/10/23 446.13 GiB | 459.56 GiB | 905.70 GiB | 87.93 Mbit/s ####################### 12/09/23 464.79 GiB | 473.17 GiB | 937.96 GiB | 91.07 Mbit/s ####################### 12/08/23 454.67 GiB | 463.48 GiB | 918.16 GiB | 89.14 Mbit/s ####################### 12/07/23 463.82 GiB | 472.84 GiB | 936.65 GiB | 90.94 Mbit/s ####################### 12/06/23 670.01 GiB | 680.55 GiB | 1.32 TiB | 131.13 Mbit/s ################################## 12/05/23 808.50 GiB | 817.32 GiB | 1.59 TiB | 157.85 Mbit/s ######################################### 12/04/23 854.09 GiB | 866.43 GiB | 1.68 TiB | 167.05 Mbit/s ########################################### 12/03/23 782.20 GiB | 799.00 GiB | 1.54 TiB | 153.52 Mbit/s ######################################## 12/02/23 805.18 GiB | 817.91 GiB | 1.59 TiB | 157.59 Mbit/s ######################################### 12/01/23 733.80 GiB | 745.35 GiB | 1.44 TiB | 143.61 Mbit/s ##################################### 11/30/23 742.48 GiB | 756.56 GiB | 1.46 TiB | 145.54 Mbit/s ##################################### 11/29/23 657.90 GiB | 673.66 GiB | 1.30 TiB | 129.28 Mbit/s ################################# In general, are there any tweaks to reduce relay CPU usage on a slow processor? I did seemingly most of what is possible, ethtool, iptables, sysctl, etc. How long before the Rust-based Tor will be ready for use on relays? -- With respect, Roman

4 5

Re: [tor-relays] bridges for Lox
by Holonet 04 Mar '24

04 Mar '24

> On 27 Feb 2024, at 15:39, boldsuck <lists(a)for-privacy.net> wrote: > On Dienstag, 27. Februar 2024 14:52:00 CET Corl3ss via tor-relays wrote: >> On 26/02/2024 21:03, Toralf Förster via tor-relays wrote: >>> On 2/26/24 20:07, meskio wrote: >>>> At the moment we're >>>> looking for 10 new bridges for Lox. >>> 9 left >> >> And one more added, so 8 left. > +1 = 7 left Added one. 6 left.

4 3

bridges for Lox
by meskio 28 Feb '24

28 Feb '24

Hello, We are developing a reputation based bridge distributor called Lox[0] and are preparing to make a call for users to test it in Tor Browser Alpha. In order to do this, we need to have some new bridges that can be distributed by Lox. Do you want to give us a hand running a bridge (or few) for Lox? At the moment we're looking for 10 new bridges for Lox. Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, but will instead accept bridges with the 'BridgeDistribution lox' configured in torrc. To set up a bridge for Lox, configure a normal obfs4 bridge[1] and simply include the following line in torrc: BridgeDistribution lox As Lox is only going to be released for testing, you might not see a lot of traffic on Lox bridges at the moment. However, these bridges will be very useful for us to improve Lox and see what works and what does not. Thank you [0] https://gitlab.torproject.org/tpo/anti-censorship/lox [1] https://community.torproject.org/relay/setup/bridge/ -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

5 13

Re: [tor-relays] tor-relays Digest, Vol 157, Issue 19
by badgerfighter 27 Feb '24

27 Feb '24

+1 incoming. On Tuesday, February 27th, 2024 at 04:17, tor-relays-request(a)lists.torproject.org <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. bridges for Lox (meskio) > 2. Re: bridges for Lox (Toralf F?rster) > 3. Re: bridges for Lox (Toralf F?rster) > 4. Re: bridges for Lox (meskio) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 26 Feb 2024 20:07:45 +0100 > From: meskio meskio(a)torproject.org > > To: tor-relays tor-relays(a)lists.torproject.org > > Subject: [tor-relays] bridges for Lox > Message-ID: 170897446522.1760.2953283832616396350@localhost > > Content-Type: text/plain; charset="utf-8" > > Hello, > > We are developing a reputation based bridge distributor called Lox[0] and are > preparing to make a call for users to test it in Tor Browser Alpha. In order to > do this, we need to have some new bridges that can be distributed by Lox. Do you > want to give us a hand running a bridge (or few) for Lox? At the moment we're > looking for 10 new bridges for Lox. > > Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now, > but will instead accept bridges with the 'BridgeDistribution lox' configured in > torrc. > > To set up a bridge for Lox, configure a normal obfs4 bridge[1] and simply > include the following line in torrc: > BridgeDistribution lox > > As Lox is only going to be released for testing, you might not see a lot of > traffic on Lox bridges at the moment. However, these bridges will be very useful > for us to improve Lox and see what works and what does not. > > Thank you > > > [0] https://gitlab.torproject.org/tpo/anti-censorship/lox > [1] https://community.torproject.org/relay/setup/bridge/ > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan. >

1 0

Tor Relay Automatic PMTU Testing
by pasture_clubbed242＠simplelogin.com 22 Feb '24

22 Feb '24

Greetings, I believe there is a larger sized guard relay that has been having MTU issues for about a week. All connections with packets above a certain size are dropped. This results in partially loaded or broken webpages, broken file downloads, etc. Do Tor directory authorities test MTU (implicitly by speed test?) when testing relays? Wondering if anyone else noticed this or if it would be handled automatically by dir authorities. Thanks all

3 3

VPS w/FDE suggestions?
by MRob 22 Feb '24

22 Feb '24

Hello- Im looking for <= $6/mo VPS suggestions for general non-tor server and also for tor. Some super-cheap hosts pre-install O/S and give root but I want to install O/S myself so can put in FDE. Hard to see which hosts can do this. I tried Linode before and yes, could get FDE ($5 1GB, 1CPU, 25GB, 1TB) Is IONOS any good? Can I get FDE there?? ($2 1GB, 1CPU, 10GB, ?TB) ($3 2GB, 2CPU, 80GB, ?TB) ($6 4GB, 2CPU, 160GB, ?TB) Others caught my eye: hudsonvalleyhost ($3.95 1GB, 1CPU, 25GB, 20TB) ($6.95 2GB, 2CPU, 50GB, 20TB) liquidweb ($5 1GB, 1CPU, 30GB, 1TB) digitalocean ($6 1GB, 1CPU, 25GB, 20TB) ovhcloud ($4.20 2GB, 1CPU, 20GB, 100Mbps unmetered) ($5.50 2GB, 2CPU, 40GB, 500Mbps unmetered) brownrice ($5.95 3GB, 1CPU, 10GB, unlimited)

4 4

Relay again saying it's new
by Keifer Bly 21 Feb '24

21 Feb '24

Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… is again saying it's new despite that it's been running for a few years now. Second time this has happened. Thanks. --Keifer

1 0

7000 concurrent connections
by snowmanonahoe＠skiff.com 20 Feb '24

20 Feb '24

Hello all, I'm interested in running a relay. I should meet all the requirements for a guard/middle, except handling 7000 concurrent connections, which I'm unsure of. The website seems to tell me to try it and see what happens, but what exactly am I watching out for? Is the router going to fail entirely, slow down, or something else? Thanks in advance.

2 1

webtunnel bridge docker image still uses 0.4.7.13
by Carlo P. 20 Feb '24

20 Feb '24

Hi, with Tor version 0.4.7.x being EOL, the docker image for the webtunnel bridge deserves an update, as it still uses 0.4.7.13 ! Regards, C. -- Sent with https://mailfence.com Secure and private email

2 1

Getting spammed with 404 "Consensus is too old" warnings
by snowmanonahoe＠skiff.com 17 Feb '24

17 Feb '24

Hello all, Obfs4 bridge. Here is the exact warning text: Received http status code 404 ("Consensus is too old") from server 203.0.113.45:443 while fetching consensus directory. They appear in irregular intervals between 2 and 45 minutes. The heartbeat messages indicate the relay is working fine. The IP address is the same every time, and it's not mine. Anything to worry about?

1 0

Next Tor Relay Operator Meetup - 2024-01-27 @ 19:00 UTC
by gus 12 Feb '24

12 Feb '24

Dear Tor relay operators and volunteers, Save the date: the next Tor Relay Operator Meetup will happen on Saturday, January 27 at 19 UTC! We're still working on the agenda for this meetup, however feel free to add your topics directly to the ticket or just reply to the mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/84 Where: Room link: https://tor.meet.coop/gus-og0-x74-dzn When: January 27, 19:00 UTC Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ Registration No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

2 3

Way to be notified when relay goes offline?
by Keifer Bly 09 Feb '24

09 Feb '24

Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… went offline for a few days, and I was unaware. Is there a way to be notified when a relay goes offline? Thanks. --Keifer

10 10

Re: [tor-relays] request for receipes MULTI-instances of ethe4 Guard, Bridge, Exits, snowflake , Tunnel, or both DEBIAN and OpenBSD
by Isaac Grover, Aileron I.T. 08 Feb '24

08 Feb '24

Hi C, Could nusenu's ansible playbook "relayor" work for your request? More info at https://github.com/nusenu/ansible-relayor Make your day great, Isaac Grover, President/vCIO Aileron I.T. - " Because #ProactiveIsBetter " O: 715-377-0440, F:715-690-1029, W: www.aileronit.com

1 0

Relay in AT marked as DE in metrics
by Carlo P. 04 Feb '24

04 Feb '24

Hello, I have a relay on 152.53.17.183 / 2a0a:4cc0:1:1333::beef which is listed as "German" in metrics.torproject.org, but actually it is in Austria (see e.g. whatismyip.com) Is this the right place to request a fix ? Thanks, C. -- Sent with https://mailfence.com Secure and private email

3 3

Relay first seen reset on Tor metrics
by Zachary 30 Jan '24

30 Jan '24

The "first seen" date on my relay A00E3AAF5A24DC69740FA7A3A1C4A0ECB7972722 Got reset today while I was at work. It's not a problem and I don't particularly care, but is there anything that would cause this? IP hasn't changed, Tor version hasn't changed, etc. Thanks, Zachary

2 1

Setting up HTML page for exit relay
by templeos＠skiff.com 29 Jan '24

29 Jan '24

If I want to serve an HTML page for my exit node do I need Apache2/nginx or can I just modify my torrc?

3 2

tor relayS! stuck at 100% bootstrapped - not kickstarting 8B6A6D02A80A7CBB1ED0630150D8D9F9F7D471AF
by eff_03675549＠posteo.se 29 Jan '24

29 Jan '24

Hi. I am trying several Singapoor relays stuck at 100% bootstrapped without any coming speed evaluation nor id key attributions, 8B6A6D02A80A7CBB1ED0630150D8D9F9F7D471AF one middle/guard out of 4/5 came out witn keys an shows in relay search still without any speed attribution now over 48 hours, the others (guards, exit) are tusk at 100% bootstrapped. all in singapoor. Your kind evaluation please. an.

1 0

What a mess with the database of 'metrics.torproject.org'!
by Tschador 24 Jan '24

24 Jan '24

Example: Fingerprint: 9D5A7A81BC6194555CE751F75FB196E4A3982CC5 This relay appears to be less than 2 weeks old. Uptime 43 days 13 hours 30 minutes and 17 seconds First Seen 2024-01-10 16:00:00 (14 days 2 hours 32 minutes and 41 seconds) Last Restarted 2023-12-12 05:02:24 When will it be fixed? Regards

1 0

Why is Cloudflare displayed when I do a speed test?
by templeos＠skiff.com 19 Jan '24

19 Jan '24

A blog post I discovered brought up that when they perform a speed test through Tor browser, Cloudflare is quite frequently displayed as the local host. I had the same result. Is there a reason for this, like perhaps the exit relay is proxied through Cloudflare? You can easily replicate this yourself by going to speedtest.net in Tor Browser.

1 0

A new kind of attack?
by Chris Enkidu-6 19 Jan '24

19 Jan '24

I've noticed a new kind of possible attack on some of my relays, as early as Dec.23 which causes huge spikes of outbound traffic that eventually maxes out RAM and crashes Tor. The newest one today lasted for 5 hours switching between two of the three relays on the same IP. During the attack, Tor becomes so busy processing the traffic that it becomes unresponsive to new connections for minutes at a time and effectively becomes a zombie exclusively processing the attacker's traffic until it eventually crashes and restarts. The interesting part is that when Tor restarts, it doesn't start from scratch building new circuits but it starts right from where it left out and keeps processing the previous connections. I have tried shutting down Tor for over 5 minutes and within one minute of restart, The RAM maxes out and the outbound traffic reaches the previous heights. This has been happening, not to all relays but to a select group of relays at a time and unless you're monitoring your Tor port from outside, you may not notice it's unresponsive. Another way to see if it's happening to you too is to check your monthly history on the metrics page and look for spikes of written bytes or sudden decrease of read bytes where you see a big gap between the two. I have included charts and excerpts from the log in my post in Tor forum at below link: https://forum.torproject.org/t/new-kind-of-attack/11122 I'd appreciate your insights and comments. Thank you.

6 5

Re: [tor-relays] Relay in Japan being marked as a US relay?
by 0tpcqovw＠duck.com 18 Jan '24

18 Jan '24

https://www.infobyip.com/ip-198.13.48.219.html Shows Japan! Malcolm On Thu, Jan 18, 2024 at 4:00 PM NodNet < tor_at_nodnetwork.org_0tpcqovw(a)duck.com> wrote: > I think tor and Tor Project use IPFire's DB for GeoIP lookups, and > 198.13.48.219 shows the following: > > NETWORK: 198.13.48.0/20 > AUTONOMOUS SYSTEM: AS20473 - AS-CHOOPA > COUNTRY: United States of America > > https://www.ipfire.org/projects/location/lookup/198.13.48.219 > > On 1/18/2024 11:22 AM, Jag Talon wrote: > > Hello, > > > > I have a relay in Japan with the IP of 198.13.48.219, but it's being > > marked as being in the US. I've tried using different websites like > > www.iplocation.net, iplocation.io, and www.wolframalpha.com and > > they're all telling me that the IP is in Japan. > > > > I'm wondering if perhaps there's an issue with the GeoIP lookup? Or > > perhaps an outdated database? > > > > Thanks! > > > > > > _______________________________________________ > > 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 >

2 1

Relay in Japan being marked as a US relay?
by Jag Talon 18 Jan '24

18 Jan '24

Hello, I have a relay in Japan with the IP of 198.13.48.219, but it's being marked as being in the US. I've tried using different websites like www.iplocation.net, iplocation.io, and www.wolframalpha.com and they're all telling me that the IP is in Japan. I'm wondering if perhaps there's an issue with the GeoIP lookup? Or perhaps an outdated database? Thanks! -- Jag Talon Designer for the Tor Project

8 10

PSA: Tor 0.4.7 reaches end of life (EOL) on 2024-01-31
by Georg Koppen 17 Jan '24

17 Jan '24

Hello! In case it affects you as you are still running your relay or bridge on Tor 0.4.7.x: the 0.4.7 series is going EOL on *2024-01-31* (roughly in 2 weeks from now). That's currently still 1346 relays, which means roughly 15% of the advertised bandwidth of the network (and 964 bridges, which means roughly 45% of the advertised bridges bandwidth). Please make sure you have upgraded to the 0.4.8.x series by then. Supported releases in general can be found on the network team wiki.[1] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele…

1 0

Relay that's been running for a long time suddenly saying it's new?
by Keifer Bly 17 Jan '24

17 Jan '24

Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36… is suddenly saying it's a new relay. Don't know why this would happen as it's been running for a few years, but suddenly saying it's new? Thanks. --Keifer

6 6

Re: [tor-relays] Relay not connecting
by denny.obreham＠a-n-o-n-y-m-e.net 16 Jan '24

16 Jan '24

> On 01/16/2024 02:48 AM Chris Enkidu-6 wrote .. > If > you're running other services on the same server of course the heavy > load might disrupt those services as well, which is why it's always a > good idea to only run Tor on the server and not to mix it with other > services. That is the funny thing, everything else was working fine. Only the Tor relays experienced connection problems. Even the Tor bridge seemed to be running fine. > And in the long run, if you find that you don't > have the resources or patience to deal with such heavy load, consider > running a middle/Guard relay instead of an Exit. They're much easier to > deal with during an attack. But don't quit. It'll pass. I'm still in the process of gaining experience but don't worry about me quitting, I consider this my new hobby. My servers are exclusively dedicated to this - so there is nothing important on them for me to lose. Also, I pride myself on running exclusively exit relays as this is what is apparently needed and thus it is where the challenge lies for me. Hi, I didn't see your original email and I don't currently have it in my inbox to reply to it directly but I can tell you by looking at your metrics history for "Alberta", indeed you had the same problem on Dec.18 that happened to my relays. The attackers seem to be picking a group of relays at a time and move on to others and it may be a while before they come back again. However the problem gets amplified if you're running an exit relay without having large enough resources to deal with all this traffic. I'm not running an exit relay, so I have to deal with the problem for a few hours, but all this outgoing traffic from my relay and other relays that are under attack will inevitably end up at exit relays. This means that even if they move on from my relay to another one, the traffic will still continue to poor into exit relays, so the duration of the attack for an exit relay may be much longer. This shouldn't stop you from bringing your rely back up. You're not doing anything wrong and there's nothing wrong with your set up. If you're running other services on the same server of course the heavy load might disrupt those services as well, which is why it's always a good idea to only run Tor on the server and not to mix it with other services. My suggestion for the time being, keep running my firewall scripts as they do help making the duration of the attack shorter by putting some of those IP addresses in the block list and help making it less painful and see how it goes. And in the long run, if you find that you don't have the resources or patience to deal with such heavy load, consider running a middle/Guard relay instead of an Exit. They're much easier to deal with during an attack. But don't quit. It'll pass. Cheers. On 1/15/2024 8:14 PM, denny.obreham(a)a-n-o-n-y-m-e.net wrote: > > Sorry, but I'm going to vent a little bit. I'm not a network > specialist, so 11 days ago I sent the following email to this mailing > list asking for help because two of my Tor exit relays were completely > frozen and I was unable to put them online again. > > > Nobody answered, not even a comment. No wait, there was one person - > very active on this mailing list recently - who sent me an email > personally to tell me that I was an idiot (referring to what, I don't > know) who should kill himself. Adding furthermore that if I didn't > commit suicide within 72 hours, he would personally come to my house > and kill me with a Glock 9 mm. Fun stuff, very disturbing. > > > Anyway, no serious answers, someone calling m e an idiot: I tried to > look as best as I could at what I did wrong. Couldn't find anything. > My only available solution was to rebuild completely my server, > something I wanted to do for a while because of other undesired quirks > that were bothering me with my setup. I knew it would take a long time > - which I didn't really have - but I finally finished my new setup > yesterday. (Don't look for 25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57 or > the bridge, they have been shut down for the moment.) > > > Today, I read a line from Chris Endiku-6 saying: "Thereâs something > going on for a while and I havenât seen any mentions of it." The exact > problem I mentioned! He says it goes "as early as Dec.23"; my problem > goes to Dec 18 as shown in my previous email. Also, not mentioned in > my previous email, before I renewed my setup, my tor-ddos firewall > rules (I use the ones f rom Endiku-6) had blocked about 5 times more > IP than usual - if that can be useful information to anyone. > > > Sorry for the rent, I just needed to vent a little: There was > something wrong, and I wasn't crazy or incompetent! > > > I still would like to know how to restart such a relay, if this > happens again in the future - other than reinstalling the entire > server, that is. > > > Thanks in advance. > > > On 01/06/2024 01:52 PM denny.obreham(a)a-n-o-n-y-m-e.net wrote .. > > I manage the two following exit relays: * > https://metrics.torproject.org/rs.html#details/25FC41154DCB2CAE3ABD7 4A8DFCD5B90D2CFFD57* > https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF 7D8F65B5881B7D4C97C > They are both on the same IP and servers. A few hours ago they > lost contact even though I have both Apache and I2P servers on the > same machine that are reachable. The weird log messages seem to go > back to Dec 18, after a restart: ``` Dec 18 07:49:47 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bootstrapped 100% (done): Done Dec 18 > 07:54:18 a-n-o-n-y-m-e Tor-Alberta[904715]: 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. Dec 18 07:57:11 > a-n-o-n-y-m-e Tor-Alberta[904715]: 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. [14254 similar message(s) suppressed in > last 180 seconds] ``` There are a few more of these messages > appearing afterward (My bandwidth is unlimited). This is the > typical Heartbeat that comes afterward: ``` Dec 18 13:49:42 > a-n-o-n-y-m-e Tor-Alberta[904715]: Heartbeat: Tor's uptime is 6:00 > hours, with 476 circuits open. I've sent 30.87 GB and received > 9.04 GB. I've received 13401 connections on IPv4 and 0 on IPv6. > I've made 46754 connections with IPv4 and 0 with IPv6. Dec 18 > 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: While not > bootstrapping, fetched this many bytes: 6412201 (server descriptor > fetch); 1424 (server descriptor upload); 376002 (consensus > network-status fetch); 57564 (microdescriptor fetch) Dec 18 > 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Circuit handshake > stats since last time: 8/8 TAP, 1356688/6457307 NTor. Dec 18 > 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Since startup we > initiated 0 and received 0 v1 connections; initiated 0 and > received 0 v2 connections; initiated 0 and received 0 v3 > connections; initiated 0 and received 429 v4 connections; > initiated 285 and received 11137 v5 connections. Dec 18 13:49:42 > a-n-o-n-y-m-e Tor-Alberta[904715]: Heartbeat: DoS mitigation since > startup: 0 circuits killed with too many cells, 0 circuits > rejected, 0 marked addresses, 0 marked addresses for max queue, 0 > same address concurrent connections rejected, 0 connections > rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. ``` > Then I have this kind of message appearing: ``` Dec 18 14:13:23 > a-n-o-n-y-m-e Tor-Alberta[904715]: No circuits are opened. Relaxed > timeout for circuit 4487 (a Measuring circuit timeout 3-hop > circuit in state doing handshakes with channel state open) to > 60000ms. However, it appears the circuit has timed out anyway. [4 > similar message(s) suppressed in last 3300 seconds] ``` Then a few > days later, this bug report: ``` Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: tor_bug_occurred_(): Bug: > ../src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal > assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: > Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) > failed in conflux_pick_first_leg at ../src/core/or/conflux.c:567. > Stack trace: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(log_backtrace_impl+0x5b) > [0x55651f95b37b] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_bug_occurred_+0x18a) > [0x55651f97294a] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /usr/bin/tor(conflux_decide_next_circ+0x40e) [0x55651fa12afe] (on > Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > Bug: /usr/bin/tor(circuit_get_package_window+0x75) > [0x55651fa12ec5] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x9ed63) [0x55651f908d63] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /usr/bin/tor(connection_edge_package_raw_inbuf+0xae) > [0x55651f90b80e] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /usr/bin/tor(connection_edge_process_inbuf+0x6f) [0x55651fa2b9df] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x1c2fb4) [0x55651fa2cfb4] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x73ffc) [0x55651f8ddffc] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x1ff58) [0x7fcee899bf58] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x577) > [0x7fcee899d8a7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(do_main_loop+0x127) > [0x55651f8de7c7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_run_main+0x215) > [0x55651f8e2805] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_main+0x4d) > [0x55651f8e2c6d] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(main+0x1d) [0x55651f8d4dcd] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fcee80a8d90] (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) > [0x7fcee80a8e40] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(_start+0x25) > [0x55651f8d4e25] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching > client sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux > 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: > 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 > 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > conflux_pick_first_leg(): Bug: Matching server sets: (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 > launched. Delivered: 75; teardown: 0; Current: (nil), Previous: > (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: End conflux > set dump (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: circuit_get_package_window(): Bug: Conflux > has no circuit to send on. Circuit 0x556536e76c20 idx 138 marked > at line ../src/core/or/command.c:663 (on Tor 0.4.8.10 ) Dec 21 > 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: tor_bug_occurred_(): > Bug: ../src/core/or/conflux.c:567: conflux_pick_first_leg: > Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on > Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) > <= 0) failed in conflux_pick_first_leg at > ../src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) Dec > 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: > /usr/bin/tor(log_backtrace_impl+0x5b) [0x55651f95b37b] (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: > /usr/bin/tor(tor_bug_occurred_+0x18a) [0x55651f97294a] (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: > /usr/bin/tor(conflux_decide_next_circ+0x40e) [0x55651fa12afe] (on > Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > Bug: /usr/bin/tor(circuit_get_package_window+0x75) > [0x55651fa12ec5] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x9ed63) [0x55651f908d63] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /usr/bin/tor(connection_edge_package_raw_inbuf+0xae) > [0x55651f90b80e] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /usr/bin/tor(connection_edge_process_inbuf+0x6f) [0x55651fa2b9df] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x1c34dd) [0x55651fa2d4dd] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x73ffc) [0x55651f8ddffc] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x1ff58) [0x7fcee899bf58] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x577) > [0x7fcee899d8a7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(do_main_loop+0x127) > [0x55651f8de7c7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_run_main+0x215) > [0x55651f8e2805] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_main+0x4d) > [0x55651f8e2c6d] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(main+0x1d) [0x55651f8d4dcd] > (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fcee80a8d90] (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) > [0x7fcee80a8e40] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: Bug: /usr/bin/tor(_start+0x25) > [0x55651f8d4e25] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching > client sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux > 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: > 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 > 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > conflux_pick_first_leg(): Bug: Matching server sets: (on Tor > 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: > conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 > launched. Delivered: 75; teardown: 0; Current: (nil), Previous: > (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: End conflux > set dump (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e > Tor-Alberta[904715]: circuit_get_package_window(): Bug: Conflux > has no circuit to send on. Circuit 0x556536e76c20 idx 138 marked > at line ../src/core/or/command.c:663 (on Tor 0.4.8.10 ) ``` It is > then an alternation of these three last messages (Heartbeat + "No > circuits are opened" + bug) until yesterday where I get a series > of these messages: ``` Jan 5 21:58:59 a-n-o-n-y-m-e > Tor-Alberta[904715]: Failed to find node for hop #1 of our path. > Discarding this circuit. Jan 5 21:58:59 a-n-o-n-y-m-e > Tor-Alberta[904715]: Our circuit 0 (id: 355722) died due to an > invalid selected path, purpose Unlinked conflux circuit. This may > be a torrc configuration issue, or a bug. ``` At this point, I > learned that my relays were down via Tor Weather. I restarted the > relays - even rebooted the whole server - and both relays seem to > be unable to connect to the network. Here's a sample: ``` Jan 6 > 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: 254 connections have > failed: Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: 254 > connections died in state connect()ing with SSL state (No SSL > object) Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: Problem > bootstrapping. Stuck at 5% (conn): Connecting to a relay. > (Connection timed out; TIMEOUT; count 256; recommendation warn; > host 65369D044C659CD299E35763914FFD0FC9AD4509 at > 92.205.161.164:80) ``` I also have a bridge on this server > (different IP) and it seems OK ( > https://metrics.torproject.org/rs.html#details/7CEB9D16C5218FE1A9BAB 8E8A6EA9471D2E1F9B8 > ). Last messages after the server reboot are: ``` Jan 6 08:34:17 > a-n-o-n-y-m-e Tor-Nestor[998]: Bootstrapped 100% (done): Done Jan > 6 08:35:21 a-n-o-n-y-m-e Tor-Nestor[998]: Performing bandwidth > self-test...done. Jan 6 09:54:22 a-n-o-n-y-m-e Tor-Nestor[998]: No > circuits are opened. Relaxed timeout for circuit 527 (a Measuring > circuit timeout 3-hop circuit in state doing handshakes with > channel state open) to 60000ms. However, it appears the circuit > has timed out anyway. ``` I have stopped both relays until I > figure out what is going on. Help would be appreciated. > >

1 0

Re: [tor-relays] Relay not connecting
by denny.obreham＠a-n-o-n-y-m-e.net 16 Jan '24

16 Jan '24

> According to > https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8 F65B5881B7D4C97C > the relay is back since 1-2 days, good. Exiting to port 22 might lead > to a lot of complaints ending at your ISP or yourself. Default SSH. Yes, as I said I put it back online by rebuilding my server completely. Did not know that about port 22. I used a variant of the ReducedExitPolicy which accepts port 22 according to https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy . > Did you check > https://gitlab.torproject.org/tpo/core/tor/-/issues/ for the bug you > reported? I wasn't even sure if it was a bug, if I did something wrong, or if it was related to my ISP; hence my question on the mailing list.

1 0

Re: [tor-relays] Relay not connecting
by denny.obreham＠a-n-o-n-y-m-e.net 16 Jan '24

16 Jan '24

Sorry, but I'm going to vent a little bit. I'm not a network specialist, so 11 days ago I sent the following email to this mailing list asking for help because two of my Tor exit relays were completely frozen and I was unable to put them online again. Nobody answered, not even a comment. No wait, there was one person - very active on this mailing list recently - who sent me an email personally to tell me that I was an idiot (referring to what, I don't know) who should kill himself. Adding furthermore that if I didn't commit suicide within 72 hours, he would personally come to my house and kill me with a Glock 9 mm. Fun stuff, very disturbing. Anyway, no serious answers, someone calling me an idiot: I tried to look as best as I could at what I did wrong. Couldn't find anything. My only available solution was to rebuild completely my server, something I wanted to do for a while because of other undesired quirks that were bothering me with my setup. I knew it would take a long time - which I didn't really have - but I finally finished my new setup yesterday. (Don't look for 25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57 or the bridge, they have been shut down for the moment.) Today, I read a line from Chris Endiku-6 saying: "Thereâs something going on for a while and I havenât seen any mentions of it." The exact problem I mentioned! He says it goes "as early as Dec.23"; my problem goes to Dec 18 as shown in my previous email. Also, not mentioned in my previous email, before I renewed my setup, my tor-ddos firewall rules (I use the ones from Endiku-6) had blocked about 5 times more IP than usual - if that can be useful information to anyone. Sorry for the rent, I just needed to vent a little: There was something wrong, and I wasn't crazy or incompetent! I still would like to know how to restart such a relay, if this happens again in the future - other than reinstalling the entire server, that is. Thanks in advance. On 01/06/2024 01:52 PM denny.obreham(a)a-n-o-n-y-m-e.net wrote .. I manage the two following exit relays: * https://metrics.torproject.org/rs.html#details/25FC41154DCB2CAE3ABD7 4A8DFCD5B90D2CFFD57 * https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF 7D8F65B5881B7D4C97C They are both on the same IP and servers. A few hours ago they lost contact even though I have both Apache and I2P servers on the same machine that are reachable. The weird log messages seem to go back to Dec 18, after a restart: ``` Dec 18 07:49:47 a-n-o-n-y-m-e Tor-Alberta[904715]: Bootstrapped 100% (done): Done Dec 18 07:54:18 a-n-o-n-y-m-e Tor-Alberta[904715]: 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. Dec 18 07:57:11 a-n-o-n-y-m-e Tor-Alberta[904715]: 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. [14254 similar message(s) suppressed in last 180 seconds] ``` There are a few more of these messages appearing afterward (My bandwidth is unlimited). This is the typical Heartbeat that comes afterward: ``` Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Heartbeat: Tor's uptime is 6:00 hours, with 476 circuits open. I've sent 30.87 GB and received 9.04 GB. I've received 13401 connections on IPv4 and 0 on IPv6. I've made 46754 connections with IPv4 and 0 with IPv6. Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: While not bootstrapping, fetched this many bytes: 6412201 (server descriptor fetch); 1424 (server descriptor upload); 376002 (consensus network-status fetch); 57564 (microdescriptor fetch) Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Circuit handshake stats since last time: 8/8 TAP, 1356688/6457307 NTor. Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 429 v4 connections; initiated 285 and received 11137 v5 connections. Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. ``` Then I have this kind of message appearing: ``` Dec 18 14:13:23 a-n-o-n-y-m-e Tor-Alberta[904715]: No circuits are opened. Relaxed timeout for circuit 4487 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [4 similar message(s) suppressed in last 3300 seconds] ``` Then a few days later, this bug report: ``` Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: tor_bug_occurred_(): Bug: ../src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at ../src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(log_backtrace_impl+0x5b) [0x55651f95b37b] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_bug_occurred_+0x18a) [0x55651f97294a] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(conflux_decide_next_circ+0x40e) [0x55651fa12afe] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(circuit_get_package_window+0x75) [0x55651fa12ec5] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x9ed63) [0x55651f908d63] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xae) [0x55651f90b80e] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_process_inbuf+0x6f) [0x55651fa2b9df] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x1c2fb4) [0x55651fa2cfb4] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x73ffc) [0x55651f8ddffc] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x1ff58) [0x7fcee899bf58] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x577) [0x7fcee899d8a7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(do_main_loop+0x127) [0x55651f8de7c7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_run_main+0x215) [0x55651f8e2805] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_main+0x4d) [0x55651f8e2c6d] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(main+0x1d) [0x55651f8d4dcd] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fcee80a8d90] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fcee80a8e40] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(_start+0x25) [0x55651f8d4e25] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x556536e76c20 idx 138 marked at line ../src/core/or/command.c:663 (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: tor_bug_occurred_(): Bug: ../src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at ../src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(log_backtrace_impl+0x5b) [0x55651f95b37b] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_bug_occurred_+0x18a) [0x55651f97294a] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(conflux_decide_next_circ+0x40e) [0x55651fa12afe] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(circuit_get_package_window+0x75) [0x55651fa12ec5] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x9ed63) [0x55651f908d63] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xae) [0x55651f90b80e] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_process_inbuf+0x6f) [0x55651fa2b9df] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x1c34dd) [0x55651fa2d4dd] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x73ffc) [0x55651f8ddffc] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x1ff58) [0x7fcee899bf58] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x577) [0x7fcee899d8a7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(do_main_loop+0x127) [0x55651f8de7c7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_run_main+0x215) [0x55651f8e2805] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_main+0x4d) [0x55651f8e2c6d] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(main+0x1d) [0x55651f8d4dcd] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fcee80a8d90] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fcee80a8e40] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(_start+0x25) [0x55651f8d4e25] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x556536e76c20 idx 138 marked at line ../src/core/or/command.c:663 (on Tor 0.4.8.10 ) ``` It is then an alternation of these three last messages (Heartbeat + "No circuits are opened" + bug) until yesterday where I get a series of these messages: ``` Jan 5 21:58:59 a-n-o-n-y-m-e Tor-Alberta[904715]: Failed to find node for hop #1 of our path. Discarding this circuit. Jan 5 21:58:59 a-n-o-n-y-m-e Tor-Alberta[904715]: Our circuit 0 (id: 355722) died due to an invalid selected path, purpose Unlinked conflux circuit. This may be a torrc configuration issue, or a bug. ``` At this point, I learned that my relays were down via Tor Weather. I restarted the relays - even rebooted the whole server - and both relays seem to be unable to connect to the network. Here's a sample: ``` Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: 254 connections have failed: Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: 254 connections died in state connect()ing with SSL state (No SSL object) Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out; TIMEOUT; count 256; recommendation warn; host 65369D044C659CD299E35763914FFD0FC9AD4509 at 92.205.161.164:80) ``` I also have a bridge on this server (different IP) and it seems OK ( https://metrics.torproject.org/rs.html#details/7CEB9D16C5218FE1A9BAB 8E8A6EA9471D2E1F9B8 ). Last messages after the server reboot are: ``` Jan 6 08:34:17 a-n-o-n-y-m-e Tor-Nestor[998]: Bootstrapped 100% (done): Done Jan 6 08:35:21 a-n-o-n-y-m-e Tor-Nestor[998]: Performing bandwidth self-test...done. Jan 6 09:54:22 a-n-o-n-y-m-e Tor-Nestor[998]: No circuits are opened. Relaxed timeout for circuit 527 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. ``` I have stopped both relays until I figure out what is going on. Help would be appreciated.

3 2

Relay’s first seen date got reset
by Rafo (r4fo.com) 16 Jan '24

16 Jan '24

I run the following relay: https://metrics.torproject.org/rs.html#details/6C336E553CC7E0416EBC8577A728…. I just noticed that my relay’s ‘first seen’ date got reset. Tor now thinks that my relay is less than 2 weeks old. But when you open the 6 months graph, you can see the actual ‘first seen’ date which is November 29th 2023. Is it possible to fix this ‘first seen’ date back to the actual value?

2 1

Relay reboots every 15 minutes
by torserver 15 Jan '24

15 Jan '24

Starting about a week or so the number of connections raised rapidly to 18000+ and since then my middle relay reboots every 15 minutes. Lowering the relaybandwidth to a few MBytes partly solved these reboots. Before these unplanned reboots the relay has run for months at 20 - 40 MBytes traffic without issues. The number of connections now is around 11000 per relay. How can I prevent these reboots?

1 1

Tor relay operator research
by Ana Custura 14 Jan '24

14 Jan '24

Dear operators, I'm conducting a study to understand relay operator motivations and needs, funded by OTF. If you had about 30-45 minutes to talk (completely anonymously if you wish) about your experience as a relay operator, it will really help this research, especially if you're running a relay in non-western country. If interested please reach out to me either on acute(a)torproject.org or ana(a)sr2.uk. Cheers Ana

1 0

OrNetStats Update Interval
by nusenu 14 Jan '24

14 Jan '24

Hi, OrNetStats, https://nusenu.github.io/OrNetStats/ a website for relay operators and other interested parties, showing various stats about the tor network used to update its stats on a daily basis and recently switched to ~weekly updates while still maintaining a daily granularity. If you have any expectations or opinion on how often the stats should be updated on OrNetStats please let me know. Off-list replies are fine as well. kind regards, nusenu -- https://nusenu.github.io

1 0

[To the maintainers of Tor Metrics] Metrics showing erroneous data for my two relays, can somebody responsible please take a look at the issue?
by George Hartley 11 Jan '24

11 Jan '24

Hello, for about 3 months I have been hosting two Tor relays: https://metrics.torproject.org/rs.html#details/AF42E6C77196A37F041A1A1E953E… https://metrics.torproject.org/rs.html#details/7F7D1A5BE88FA7C9358955705AE7… After doing system maintenance (mainly upgrading packages), slightly adjusting my "BandwidthRate" and "BandwidthBurst" for both relays and then rebooting the server earlier, the guard relay now shows the following on Metrics, even though the graphs still show the old, correct data: > The first time that this relay was seen in the consensus: 2024-01-10 16:00:00 (8 hours 57 minutes and 21 seconds) This is even though metrics shows an uptime of almost 16 hours?! The fingerprints did not change according to both the metrics page, and the Tor log. I did not delete or mess with each relays DataDirectory or the secret keys. I have a MyFamily setting in both relays configs: > MyFamily $AF42E6C77196A37F041A1A1E953E51B4656BDC1B, $7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0 Yet the relays don't show up as being in a family, and Metrics doesn't at all display the other relay counterpart as a family member when visiting the page for the guard or exit. There is also no line in the relays journal (from journalctl -u tor@guard) indicating that the guard relay is new to the network, and it retains its older flags. This only seems to affect my guard relay, the exit metrics page shows mostly valid data, except for the missing family member. Since I did not change anything that would cause this, this is likely a bug with the metrics page, and I would encourage you to look into it. Thank you very much, George

1 1

Re: [tor-relays] Remove my relay from relay search on Tor Metrics
by 0tpcqovw＠duck.com 09 Jan '24

09 Jan '24

I think it's after 30 days it gets automatically removed. Malcolm On Mon, Dec 25, 2023, 15:25 nemeto via tor-relays < tor-relays_at_lists.torproject.org_0tpcqovw(a)duck.com> wrote: > Hi, I set up a middle relay at first, but I changed my mind to run a > bridge to avoid blacklisting of my public IP by certain websites. Is it > possible to immediately remove my relay from relay search o > *DuckDuckGo* did not detect any trackers. More > <https://duckduckgo.com/> > Deactivate > <https://duckduckgo.com/> > Hi, > > I set up a middle relay at first, but I changed my mind to run a bridge to > avoid blacklisting of my public IP by certain websites. > > Is it possible to immediately remove my relay from relay search on Tor > Metrics? If not, when will my relay be removed from the relay list? > > Thanks! > > Nemeto > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

Relay not connecting
by denny.obreham＠a-n-o-n-y-m-e.net 06 Jan '24

06 Jan '24

I manage the two following exit relays: * https://metrics.torproject.org/rs.html#details/25FC41154DCB2CAE3ABD74A8DFCD… * https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B… They are both on the same IP and servers. A few hours ago they lost contact even though I have both Apache and I2P servers on the same machine that are reachable. The weird log messages seem to go back to Dec 18, after a restart: ``` Dec 18 07:49:47 a-n-o-n-y-m-e Tor-Alberta[904715]: Bootstrapped 100% (done): Done Dec 18 07:54:18 a-n-o-n-y-m-e Tor-Alberta[904715]: 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. Dec 18 07:57:11 a-n-o-n-y-m-e Tor-Alberta[904715]: 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. [14254 similar message(s) suppressed in last 180 seconds] ``` There are a few more of these messages appearing afterward (My bandwidth is unlimited). This is the typical Heartbeat that comes afterward: ``` Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Heartbeat: Tor's uptime is 6:00 hours, with 476 circuits open. I've sent 30.87 GB and received 9.04 GB. I've received 13401 connections on IPv4 and 0 on IPv6. I've made 46754 connections with IPv4 and 0 with IPv6. Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: While not bootstrapping, fetched this many bytes: 6412201 (server descriptor fetch); 1424 (server descriptor upload); 376002 (consensus network-status fetch); 57564 (microdescriptor fetch) Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Circuit handshake stats since last time: 8/8 TAP, 1356688/6457307 NTor. Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 429 v4 connections; initiated 285 and received 11137 v5 connections. Dec 18 13:49:42 a-n-o-n-y-m-e Tor-Alberta[904715]: Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. ``` Then I have this kind of message appearing: ``` Dec 18 14:13:23 a-n-o-n-y-m-e Tor-Alberta[904715]: No circuits are opened. Relaxed timeout for circuit 4487 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. [4 similar message(s) suppressed in last 3300 seconds] ``` Then a few days later, this bug report: ``` Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: tor_bug_occurred_(): Bug: ../src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at ../src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(log_backtrace_impl+0x5b) [0x55651f95b37b] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_bug_occurred_+0x18a) [0x55651f97294a] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(conflux_decide_next_circ+0x40e) [0x55651fa12afe] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(circuit_get_package_window+0x75) [0x55651fa12ec5] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x9ed63) [0x55651f908d63] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xae) [0x55651f90b80e] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_process_inbuf+0x6f) [0x55651fa2b9df] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x1c2fb4) [0x55651fa2cfb4] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x73ffc) [0x55651f8ddffc] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x1ff58) [0x7fcee899bf58] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x577) [0x7fcee899d8a7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(do_main_loop+0x127) [0x55651f8de7c7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_run_main+0x215) [0x55651f8e2805] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_main+0x4d) [0x55651f8e2c6d] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(main+0x1d) [0x55651f8d4dcd] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fcee80a8d90] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fcee80a8e40] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(_start+0x25) [0x55651f8d4e25] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x556536e76c20 idx 138 marked at line ../src/core/or/command.c:663 (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: tor_bug_occurred_(): Bug: ../src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at ../src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(log_backtrace_impl+0x5b) [0x55651f95b37b] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_bug_occurred_+0x18a) [0x55651f97294a] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(conflux_decide_next_circ+0x40e) [0x55651fa12afe] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(circuit_get_package_window+0x75) [0x55651fa12ec5] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x9ed63) [0x55651f908d63] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xae) [0x55651f90b80e] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(connection_edge_process_inbuf+0x6f) [0x55651fa2b9df] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x1c34dd) [0x55651fa2d4dd] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(+0x73ffc) [0x55651f8ddffc] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x1ff58) [0x7fcee899bf58] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x577) [0x7fcee899d8a7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(do_main_loop+0x127) [0x55651f8de7c7] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_run_main+0x215) [0x55651f8e2805] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(tor_main+0x4d) [0x55651f8e2c6d] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(main+0x1d) [0x55651f8d4dcd] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fcee80a8d90] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fcee80a8e40] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: Bug: /usr/bin/tor(_start+0x25) [0x55651f8d4e25] (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_log_set(): Bug: Conflux 566550141B144136: 0 linked, 0 launched. Delivered: 75; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) Dec 21 15:18:48 a-n-o-n-y-m-e Tor-Alberta[904715]: circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x556536e76c20 idx 138 marked at line ../src/core/or/command.c:663 (on Tor 0.4.8.10 ) ``` It is then an alternation of these three last messages (Heartbeat + "No circuits are opened" + bug) until yesterday where I get a series of these messages: ``` Jan 5 21:58:59 a-n-o-n-y-m-e Tor-Alberta[904715]: Failed to find node for hop #1 of our path. Discarding this circuit. Jan 5 21:58:59 a-n-o-n-y-m-e Tor-Alberta[904715]: Our circuit 0 (id: 355722) died due to an invalid selected path, purpose Unlinked conflux circuit. This may be a torrc configuration issue, or a bug. ``` At this point, I learned that my relays were down via Tor Weather. I restarted the relays - even rebooted the whole server - and both relays seem to be unable to connect to the network. Here's a sample: ``` Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: 254 connections have failed: Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: 254 connections died in state connect()ing with SSL state (No SSL object) Jan 6 09:44:46 a-n-o-n-y-m-e Tor-Alberta[5621]: Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (Connection timed out; TIMEOUT; count 256; recommendation warn; host 65369D044C659CD299E35763914FFD0FC9AD4509 at 92.205.161.164:80) ``` I also have a bridge on this server (different IP) and it seems OK ( https://metrics.torproject.org/rs.html#details/7CEB9D16C5218FE1A9BAB8E8A6EA… ). Last messages after the server reboot are: ``` Jan 6 08:34:17 a-n-o-n-y-m-e Tor-Nestor[998]: Bootstrapped 100% (done): Done Jan 6 08:35:21 a-n-o-n-y-m-e Tor-Nestor[998]: Performing bandwidth self-test...done. Jan 6 09:54:22 a-n-o-n-y-m-e Tor-Nestor[998]: No circuits are opened. Relaxed timeout for circuit 527 (a Measuring circuit timeout 3-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. ``` I have stopped both relays until I figure out what is going on. Help would be appreciated.

1 0

Remove my relay from relay search on Tor Metrics
by nemeto 27 Dec '23

27 Dec '23

Hi, I set up a middle relay at first, but I changed my mind to run a bridge to avoid blacklisting of my public IP by certain websites. Is it possible to immediately remove my relay from relay search on Tor Metrics? If not, when will my relay be removed from the relay list? Thanks! Nemeto

2 2

Reboot torservers.net @ 37C3
by Stefan Leibfarth 25 Dec '23

25 Dec '23

Hello everyone, torservers.net has been inactive for quite some time. I have organized a meeting at the 37C3 to change this in the future, if you want to. You are a representative of a non-profit who is running Tor relays and you think it could be useful to a have some kind of umbrella association? Please attend this meeting. When: 30.12.2024 0:00 Where: Saal D Link: https://events.ccc.de/congress/2023/hub/de/event/torserversnet-meeting/ If you are not @ 37C3 but you'd like to work on a future for torservers.net, please contact me via mail. All the best Leibi

1 0

Tor Relay Operators Meetup @ 37C3
by Stefan Leibfarth 25 Dec '23

25 Dec '23

Hello everyone, there will be a Tor Relay Operators Meetup @ 37C3: https://events.ccc.de/congress/2023/hub/de/event/tor-relay-operators-meetup/ As always, TROMs are open for everyone (if you have a 37C3 ticket of course) who is running a relay, wants to run a relay or just thinks about it. :-) At this point we don't have a agenda, but everyone is free to bring up questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! See you there Leibi

1 0

Relay data limit
by Dan 22 Dec '23

22 Dec '23

Hi all, I've been running a middle relay on a VPS for about 2 months now. The provider limits the monthly data transferred to 5TB but does not charge for over-usage. Instead, the bandwidth is throttled to 1Mb/s after the limit is reached until the 1st of the next month. I currently have AccountingMax set to 2.5 TB (since it's the max in each direction) and AccountingStart set to "month 1 00:00". Generally that 5TB limit is hit between the 15th and 17th of the month, causing the relay to go dormant until the 1st. What I'm wondering is: 1 - Is it better for the network if the relay is active 24/7, even if sometimes it's much slower? 2 - Will it negatively affect my relay's reputation if sometimes it's very slow? Thank you -- Dan

4 5

Re: [tor-relays] Tor: tor_bug_occurred_(): Bug: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10)
by George Hartley 21 Dec '23

21 Dec '23

Hello, this just happened again 5 days after the update to 0.4.8.10: > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] tor_bug_occurred_(): Bug: src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 )Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5d) [0x57b884d219ad] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x194) [0x57b884d38764] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x57b884dd74ee] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(circuit_get_package_window+0x6d) [0x57b884ddf7fd] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(+0x9bc59) [0x57b884cccc59] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x57b884ccce39] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x57b884df9a46] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(+0x1c03f8) [0x57b884df13f8] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(+0x6e72d) [0x57b884c9f72d] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22c45) [0x73761346dc45] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x73761346f3af] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x104) [0x57b884c9ff44] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x215) [0x57b884ca4165] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(tor_main+0x5e) [0x57b884ca45ee] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(main+0x1d) [0x57b884c9608d] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libc.so.6(+0x27cd0) [0x737612a7ecd0] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x737612a7ed8a] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(_start+0x25) [0x57b884c960e5] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_log_set(): Bug: Conflux C0292D60501F6C5F: 0 linked, 0 launched. Delivered: 29; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_log_set(): Bug: Conflux C0292D60501F6C5F: 0 linked, 0 launched. Delivered: 29; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x57b898679070 idx 522 marked at line src/core/or/command.c:663 (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] tor_bug_occurred_(): Bug: src/core/or/conflux.c:567: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: Tor 0.4.8.10: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at src/core/or/conflux.c:567. Stack trace: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5d) [0x57b884d219ad] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x194) [0x57b884d38764] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x57b884dd74ee] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(circuit_get_package_window+0x6d) [0x57b884ddf7fd] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(+0x9bc59) [0x57b884cccc59] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x57b884ccce39] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x57b884df9a46] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(+0x1c096f) [0x57b884df196f] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(+0x6e72d) [0x57b884c9f72d] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22c45) [0x73761346dc45] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x73761346f3af] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x104) [0x57b884c9ff44] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x215) [0x57b884ca4165] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(tor_main+0x5e) [0x57b884ca45ee] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(main+0x1d) [0x57b884c9608d] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libc.so.6(+0x27cd0) [0x737612a7ecd0] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x737612a7ed8a] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] Bug: /usr/bin/tor(_start+0x25) [0x57b884c960e5] (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_log_set(): Bug: Conflux C0292D60501F6C5F: 0 linked, 0 launched. Delivered: 29; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_log_set(): Bug: Conflux C0292D60501F6C5F: 0 linked, 0 launched. Delivered: 29; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.10 ) > Dec 21 13:54:54 matrix tor[558]: Dec 21 13:54:54.000 [warn] circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x57b898679070 idx 522 marked at line src/core/or/command.c:663 (on Tor 0.4.8.10 ) The relay does not seem impacted by it at all and continues pushing it's 60-80 MBit/s, but if this is really just an assertion which does not have any security, performance or privacy implications, then please maybe just make it a harmless information message. Regards, George On Monday, December 18th, 2023 at 11:12 AM, trinity pointard trinity.pointard(a)gmail.com wrote: > Hi, > > this looks related to TROVE-2023-007 / > https://gitlab.torproject.org/tpo/core/tor/-/issues/40897 . It should > no longer appear after you upgrade. > If it still does, please do come back. > > Regards, > trinity-1686a > > On Mon, 18 Dec 2023 at 07:05, George Hartley via tor-relays > tor-relays(a)lists.torproject.org wrote: > > > Hi, > > > > while going through journalctl I noticed the following entries from my exit relay and wanted to report this non-fatal assertion. > > > > I also host a Guard relay on the same VM and IP, and it did not yet assert that message. > > > > The full assert() with the stack-trace is as follows: > > > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] tor_bug_occurred_(): Bug: src/core/or/conflux.c:565: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: Tor 0.4.8.9: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at src/core/or/conflux.c:565. Stack trace: (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5d) [0x5fdf47b6a9ad] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x194) [0x5fdf47b81764] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x5fdf47c2031e] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(circuit_get_package_window+0x6d) [0x5fdf47c285ed] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x9bc59) [0x5fdf47b15c59] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x5fdf47b15e39] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x5fdf47c42866] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x1c0218) [0x5fdf47c3a218] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x6e72d) [0x5fdf47ae872d] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22c45) [0x7d444a49cc45] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7d444a49e3af] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x104) [0x5fdf47ae8f44] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x215) [0x5fdf47aed165] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_main+0x5e) [0x5fdf47aed5ee] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(main+0x1d) [0x5fdf47adf08d] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(+0x27cd0) [0x7d4449a7ecd0] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(_libc_start_main+0x8a) [0x7d4449a7ed8a] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(start+0x25) [0x5fdf47adf0e5] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x5fdf581d3460 idx 4524 marked at line src/core/or/command.c:663 (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] tor_bug_occurred(): Bug: src/core/or/conflux.c:565: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: Tor 0.4.8.9: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at src/core/or/conflux.c:565. Stack trace: (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x5d) [0x5fdf47b6a9ad] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred+0x194) [0x5fdf47b81764] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(conflux_decide_next_circ+0x3fe) [0x5fdf47c2031e] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(circuit_get_package_window+0x6d) [0x5fdf47c285ed] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x9bc59) [0x5fdf47b15c59] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0xa9) [0x5fdf47b15e39] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(connection_edge_process_inbuf+0x76) [0x5fdf47c42866] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x1c078f) [0x5fdf47c3a78f] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(+0x6e72d) [0x5fdf47ae872d] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(+0x22c45) [0x7d444a49cc45] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libevent-2.1.so.7(event_base_loop+0x4ff) [0x7d444a49e3af] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x104) [0x5fdf47ae8f44] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x215) [0x5fdf47aed165] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(tor_main+0x5e) [0x5fdf47aed5ee] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(main+0x1d) [0x5fdf47adf08d] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(+0x27cd0) [0x7d4449a7ecd0] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7d4449a7ed8a] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] Bug: /usr/bin/tor(_start+0x25) [0x5fdf47adf0e5] (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching client sets: (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: Matching server sets: (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_log_set(): Bug: Conflux 21CEFB4FACA11A02: 0 linked, 0 launched. Delivered: 7272; teardown: 0; Current: (nil), Previous: (nil) (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] conflux_pick_first_leg(): Bug: End conflux set dump (on Tor 0.4.8.9 ) > > Dec 14 16:29:36 matrix tor[575]: Dec 14 16:29:36.000 [warn] circuit_get_package_window(): Bug: Conflux has no circuit to send on. Circuit 0x5fdf581d3460 idx 4524 marked at line src/core/or/command.c:663 (on Tor 0.4.8.9 ) > > > > Note how it happened twice for the same circuit. > > > > This is the relays configuration: > > > > # Main Config > > > > User tor > > ORPort 443 IPv4Only > > DirPort 0 > > SOCKSPort 0 > > ControlPort 9051 > > ShutdownWaitLength 60 > > CookieAuthentication 1 > > Nickname TrafficGuardExit > > RelayBandwidthRate 12500 KBytes > > RelayBandwidthBurst 15000 KBytes > > DataDirectory /var/lib/tor/tor_exit > > ContactInfo 0x576768BA hartley_george(a)proton.me > > > > # Exit Policy > > > > ExitPolicy reject *:22 > > ExitPolicy reject *:25 > > ExitPolicy accept : > > > > # Node Family > > > > MyFamily $AF42E6C77196A37F041A1A1E953E51B4656BDC1B, $7F7D1A5BE88FA7C9358955705AE7AFA61EEDA2B0 > > > > # Acceleration > > > > HardwareAccel 1 > > NumCPUs 4 > > > > # Sandboxing > > > > Sandbox 1 > > > > I will try to cooperate as best as possible, but my life is kind of messy right now. > > > > And because of TROVE-2023-007, I will have to update the relay to version 0.4.8.10, and reading the change-log of that version, it might actually fix this assert. > > > > Still wanted to let you guys know. > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Dutch Relays
by Christopher Sheats 19 Dec '23

19 Dec '23

Hello, Emerald Onion is looking for co-location and IP transit opportunities in the Netherlands for deploying new exit relays. We have our own ASN, v4 and v6 IP space. Priorities are: - Free or cheap transit - Free or cheap cross-connects - Free or cheap colo - Amsterdam Internet Exchange - Netherlands Internet Exchange Working with collectives, or starting a new one, is interesting too. Please share your thoughts! -- yawnbox https://disobey.net/@yawnbox https://digitalcourage.social/@EmeraldOnion

5 5

Declining Relay Usage
by likogan 18 Dec '23

18 Dec '23

My exit relay has seen steadily decreasing traffic from 8MBps to 6MBps over the span of three weeks. It averages a load of ~50% CPU usage and ~65% RAM usage. It's rated network capacity is 17Mbps on a 10GB link. Why would traffic decrease if I have plenty of spare resources? Are there ways I can configure my server to boost traffic? <https://metrics.torproject.org/rs.html#details/292FCACE773DC259B799914A23BE…>

4 3