tor-relays December 2023

tor-relays@lists.torproject.org

28 participants
20 discussions

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] 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

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays December 2023