- tor-relays - lists.torproject.org

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

Re: [tor-relays] Declining Relay Usage
by Roman Mamedov 18 Dec '23

18 Dec '23

On Mon, 18 Dec 2023 15:58:52 +0000 George Hartley <hartley_george(a)proton.me> wrote: > I had a quick look at the manual, and it stated: > > > HardwareAccel 0|1 > > > If non-zero, try to use built-in (static) crypto hardware acceleration > when available. Can not be changed while tor is running. (Default: 0) > > A quick look at the source code tells me that Tor relies entirely on OpenSSL. > > The call-chain here is as follows: > > crypto_set_options first determines whether to enable any available OpenSSL engines based on if the variable mentioned above is non-zero or if an accelerator name has been set: > > > const bool hardware_accel = options->HardwareAccel || options->AccelName; > > This bool is then passed into crypto_global_init, where it is the first argument, fittingly named "useAccel". > > useAccel is then passed into crypto_openssl_late_init, where if HardwareAccel is the default (0) or no engine name has been specified, OpenSSL will make no attempt to load any acceleration engines. > > Here is a permalink to that last relevant function in the call chain: > > https://gitlab.torproject.org/tpo/core/tor/-/blob/main/src/lib/crypt_ops/cr… > > So yes, I think it is pretty safe to assume that if you do not set either configuration option, no OpenSSL engine will be used. > > Thank you for questioning me though, thanks to you I learned some more about Tor's inner workings, and you hopefully too :) It is not entirely clear to me what conclusion you came to after this research. If you mean that HardwareAccel is needed, I would still disagee. If I'm not mistaken the AES-NI support is implemented in OpenSSL not via an "engine" that you have to "use", it is just built-in internally on some deeper level. For a proof you can run "openssl engine" in the console of any AES-supporting machine, and you will not see any loadable engines there, aside from rdrand, which is unrelated, and "dynamic" which just means it can load some acceleration engines if it had any. And for instance VIA Padlock would show up as "padlock" in that list. Please use reply to all the mailing list. Sorry for bringing out your mail into the public, but it didn't seem to be strictly private in any case. -- With respect, Roman

2 2

Tor relay operator meetups
by telekobold 18 Dec '23

18 Dec '23

Hi, will there be a Tor relay operators meetup @37C3 [*]? Also, there were apparently no meetups in November and December this year? Kind regards telekobold [*] https://events.ccc.de/congress/2023/infos/startpage.html

2 1

Tor: Possible bug on 0.4.8.9 exit relay.
by George Hartley 18 Dec '23

18 Dec '23

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.

2 1

Issue with Relay Status Discrepancy on Tor Metrics
by Jan 18 Dec '23

18 Dec '23

Dear Tor Metrics Support Team, I hope this message finds you well. I am writing to report an issue regarding the status of my relay on Tor Metrics. According to Nyx, my relay appears to be running without any problems. However, Tor Metrics indicates that it is offline. Relay Details: Name:BtcToTheMoon IP Address: 116.203.227.107 Contact Email: janthor007(a)gmail.com I have verified through Nyx that the relay is operational, yet the status on Tor Metrics remains unchanged. I am concerned about this discrepancy and would appreciate any assistance in resolving this matter. Thank you for your attention to this issue. Your help in rectifying this discrepancy would be greatly appreciated. Sincerely, Michal

2 1

Running a high-performance pluggable transports Tor bridge (FOCI 2023 short paper)
by David Fifield 11 Dec '23

11 Dec '23

Linus Nordberg and I wrote a short paper that was presented at FOCI 2023. The topic is how to use all the available CPU capacity of a server running a Tor relay. This is how the Snowflake bridges are set up. It might also be useful for anyone running a relay that is bottleneck on the CPU. If you have ever run multiple relays on one IP address for better scaling (if you are one of the relay operators affected by the recent AuthDirMaxServersPerAddr change), you might want to experiment with this setup. The difference is that all the instances of Tor have the same relay fingerprint, so they operate like one big relay instead of many small relays. https://www.bamsoftware.com/papers/pt-bridge-hiperf/ > The pluggable transports model in Tor separates the concerns of > anonymity and circumvention by running circumvention code in a > separate process, which exchanges information with the main Tor > process over local interprocess communication. This model leads to > problems with scaling, especially for transports, like meek and > Snowflake, whose blocking resistance does not rely on there being > numerous, independently administered bridges, but which rather forward > all traffic to one or a few centralized bridges. We identify what > bottlenecks arise as a bridge scales from 500 to 10,000 simultaneous > users, and then from 10,000 to 50,000, and show ways of overcoming > them, based on our experience running a Snowflake bridge. The key idea > is running multiple Tor processes in parallel on the bridge host, with > externally synchronized identity keys.

3 4

obfs4 bridge management
by Christopher Sheats 10 Dec '23

10 Dec '23

Hello, I've has published a shell script for deploying and managing obfs4 bridges, I hope its useful to others. https://github.com/emeraldonion/bridge-management/ Feedback welcome! -- yawnbox https://disobey.net/@yawnbox https://digitalcourage.social/@EmeraldOnion

1 0

Exit operators on the 0.4.8.x series, please upgrade to 0.4.8.10 ASAP!
by Georg Koppen 10 Dec '23

10 Dec '23

Hello exit node operators! Today (2023-12-08) the Network Team has released a new Tor version, 0.4.8.10[1]. This update contains a fix to a remotely triggerable crash bug (TROVE-2023-007) affecting exit relays on the 0.4.8.x series. Please upgrade as soon as possible to maintain network stability and security if your relays are on that series. For those of you running their Tor relays using the Tor Debian repository, expect a new deb package to be available soon. Please note that this bug is specific to Tor exit relays on the 0.4.8.x series and does not impact other relays nor Tor clients or Tor powered apps (Tor Browser, Orbot, OnionShare). Thanks, Georg [1] https://forum.torproject.org/t/security-release-0-4-8-10/10536

3 2

Relay question
by Mulloch94 08 Dec '23

08 Dec '23

Greetings, I was directed to this relay subscription by the owner. I've recently started my own relay and everything has went smooth for the first few days. Then the relay mysteriously went offline for a period of 8-9 hours. Happened while I was sleeping I think, but any rate it came back on after I restarted the tor daemon and rebooted the server. I'm starting to think my firewall configurations might have been the culprit, even though I ran a very rudimentary setup. Basically just: -A INPUT -p tcp --dport <my SSH> -j ACCEPT -A INPUT -p tcp --dport 9050 -j ACCEPT -A INPUT -p tcp --dport 443 -j ACCEPT -A INPUT -p tcp --dport 80 -j ACCEPT -A INPUT -j DROP Default ACCEPT on OUTPUT My ORPort is on 443, so I don't see how this could be interfering. I noticed my server reboot got rid of all my rules, so I'm thinking that could've been the issue. If so, what other ports should I add? Do I even need a firewall for the relay? I don't do anything else with that server, so If it doesn't need a firewall to stay secure I won't use one. One more thing, I had a flag on my relay that said I needed to "update the descriptor." It went away after rebooting my server as well, could that been the issue? Sent with [Proton Mail](https://proton.me/) secure email.

3 2

Re: [tor-relays] Relay question
by denny.obreham＠a-n-o-n-y-m-e.net 08 Dec '23

08 Dec '23

For your firewall settings, you will find everything you need here: https://github.com/Enkidu-6/tor-ddos/ It is the common setting for most Tor operators. Although, I don't think it is the source of your problem and I wouldn't worry too much about it unless it happens repeatedly. The log in "/var/log/syslog" might give you some helpful hints. Denny On 12/07/2023 10:19 PM Mulloch94 via tor-relays <tor-relays(a)lists.torproject.org> wrote .. > Greetings, I was directed to this relay subscription by the owner. I've recently > started my own relay and everything has went smooth for the first few days. Then > the relay mysteriously went offline for a period of 8-9 hours. Happened while I > was sleeping I think, but any rate it came back on after I restarted the tor daemon > and rebooted the server. I'm starting to think my firewall configurations might > have been the culprit, even though I ran a very rudimentary setup. Basically just: > -A INPUT -p tcp --dport <my SSH> -j ACCEPT > -A INPUT -p tcp --dport 9050 -j ACCEPT > -A INPUT -p tcp --dport 443 -j ACCEPT > -A INPUT -p tcp --dport 80 -j ACCEPT > -A INPUT -j DROP > > Default ACCEPT on OUTPUT > > My ORPort is on 443, so I don't see how this could be interfering. I noticed my > server reboot got rid of all my rules, so I'm thinking that could've been the issue. > If so, what other ports should I add? Do I even need a firewall for the relay? > I don't do anything else with that server, so If it doesn't need a firewall to > stay secure I won't use one. One more thing, I had a flag on my relay that said > I needed to "update the descriptor." It went away after rebooting my server as > well, could that been the issue? > > Sent with [Proton Mail](https://proton.me/) secure email.

1 0