- tor-relays - lists.torproject.org

authority bandwidth measurements and latency
by Marco Moock 20 Aug '25

20 Aug '25

Hello! I operate 94DEAD24492D6D01E3DE614E8BE6B4035329A4D7 and I've seen various changes in the measured bandwidth in atlas. At the beginning, more than 10 MB/s were measured, now below 3. The machine itself didn't change, I can reach high up- and download rates if I transfer stuff via HTTP/FTP etc. I see that latency isn't that low (50ms https://atlas.ripe.net/measurements/116107380/results) and want to ask if that might be part of this situation. I dunno about the TCP settings of the authority bandwidth testing machines. Can anybody give some hints what's going on? -- Gruß Marco Send unsolicited bulk mail to 1751988041muell(a)stinkedores.dorfdsl.de

3 4

moria1 unreachable from AS202306
by Marco Moock 19 Aug '25

19 Aug '25

Hello! I cannot communicate with moria1 from 78.153.140.44 and it cannot reach my system. I can communicate with the rest of the world. For me, it looks like a firewall is blocking it, as traceroute clearly indicates a different behaviour for ICMP echo request and TCP. I've tried that multiple times. [m@teufel ~]$ traceroute -P tcp -p 9201 128.31.0.39 traceroute to 128.31.0.39 (128.31.0.39), 64 hops max, 40 byte packets 1 gw.hostglobal.plus (78.153.140.1) 0.460 ms 0.427 ms 0.349 ms 2 10.28.1.6 (10.28.1.6) 210.766 ms 353.511 ms 563.838 ms 3 ae8-209.rt.ad.rix.lv.retn.net (87.245.239.26) 25.299 ms 25.264 ms 25.228 ms 4 * ae1-5.rt.irx.fkt.de.retn.net (87.245.232.244) 51.147 ms 52.203 ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * [m@teufel ~]$ traceroute -I 128.31.0.39 traceroute to 128.31.0.39 (128.31.0.39), 64 hops max, 48 byte packets 1 gw.hostglobal.plus (78.153.140.1) 0.286 ms 1.231 ms 0.219 ms 2 10.28.1.6 (10.28.1.6) 1041.847 ms 25.035 ms 25.234 ms 3 ae8-209.rt.ad.rix.lv.retn.net (87.245.239.26) 26.015 ms 26.091 ms 26.084 ms 4 ae1-5.rt.irx.fkt.de.retn.net (87.245.232.244) 61.037 ms 53.253 ms 52.533 ms 5 * * * 6 * ae2.13.ear2.Boston1.net.lumen.tech (4.69.230.138) 135.086 ms 135.092 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * What are your opinions about this? -- Gruß Marco Send unsolicited bulk mail to 1755409526muell(a)stinkedores.dorfdsl.de

2 2

Tor relay back to 1 weight
by tor＠obscurity.app 17 Aug '25

17 Aug '25

ADA11AA7FD14CFE904C7E302CA08EFBC8AFB415D My relay jumped to 13500 weight, then back to 1. Even thought relay is really young, this is (in my opinnion) not normal behavior? Tor notice logs doesnt give any error, and relay got unmettered bandwidth.

2 1

Tor People @ WHY2025
by Alexander Hansen Færøy 11 Aug '25

11 Aug '25

Hey Relay Operators, I'll be at the upcoming WHY2025 hacker camp in the Netherlands. WHY2025 is an excellent opportunity to do a Relay Operator meetup at some point during the camp days. Who else from here is going? At the latest CCCamp, we did a meetup at the BornHack village, but we did receive some negative feedback on the noise level in that general area, so I was thinking of investigating if there is a quieter place with some good seating where we could host the meetup this time, and announce the time and location here on the list. Suggestions of locations are most welcome. I recently received a link from tornth on #tor-relays on IRC/Matrix to https://wiki.why2025.org/Project:Tor_Relays, where it's relatively easy to add "Tor Relays" as a project from your WHY2025 wiki account. Cheers, Alex -- Alexander Hansen Færøy

4 6

Low consensus weight votes from European authorities
by Skye Clayton 11 Aug '25

11 Aug '25

Hello, I’ve had a non-exit relay (602D56DFD408530F7FE3056CAF1DA413A50ECAE4) that has been getting low weight votes from authorities like tor26, gabelmoo, and maatuska, compared to other authorities like moria1 and bastet after checking with the consensus-health tor site. At first, I questioned my ISP (ATT Fiber)’s routing to Germany based on an authority IP so I speedtested to four speedtest.net servers in Nuremberg but I received expected bw and around 100ms ping. Regardless, my relay hasn’t had anywhere as much traffic as it should have, and my relay is essentially offering resources to the Tor network that are being devalued right now. My relay’s consensus weight is around 3000, even though moria1 and bastet vote mine around 10000. I would also ask for the Tor developers’ reasoning for using median of authorities in consensus weighting rather than mean since in my mind, if no authorities are malicious/compromised to give false values, then mean would give a more accurate representation of actual measured bw performance from the authorities, IMO. Is median only used because of a large prevalence of extremely skewed bw vote distributions? Can this be remedied in software to allow for mean usage later on? Any help would be appreciated :)

2 1

FW: Re: Tor
by C. Pe. 11 Aug '25

11 Aug '25

forgot to copy the list. ---------------------------------------- Betreff: FW: Re: [tor-relays] Tor Von: C. Pe. <peca-relay(a)mailfence.com> An: CIP <ciptorrelays(a)gmail.com> Datum: 09.08.2025, 17:10:51 Hi, after looking at the first five entries from your list, I observe one common pattern: - Each relay has got a reachable IPv6 address (next to IPv4) - Each relay has an IPv4 exit policy - Each relay has got NO IPv6 exit policy (i.e. "reject 1-65535") Could that be the reason? You have, so to say, an IPv4-exit and at the same time an IPv6 middle-only-relay. (Please note, that I am NOT a member of torproject.org, but just a bridge and non-exit relay operator, so I do not have any further insight) Regards, C. Am 08.08.2025 um 05:13, CIP via tor-relays <tor-relays(a)lists.torproject.org> schrieb: Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

3 3

No update of bridge distribution method?
by C. Pe. 09 Aug '25

09 Aug '25

Hello all, next to my posts about the NAT and non-default IP for bridges topic, I would like to draw your attention to my observation, that somehow, bridge distribution seems not updating and hence no distribution and no traffic. Please refer to the below examples, which all are configured properly without any "special" situation: E80088962F97FE190D734D67E0C656C2A6EADEE7 (webtunnel, on distribution method "none" since more than a week, despite method manually set in torrc) 45E1449B8B87ACFE6AF40CD33E91DFC3CB9B7488 (obfs4, this one is active way longer than indicated in "first seen", also shown as distribution "none") Is something wrong with the distribution DB ? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

1 0

Tor
by CIP 09 Aug '25

09 Aug '25

Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC

3 2

QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 07 Aug '25

07 Aug '25

Dear experts, I have a special question, for which I could not find 100% clear documentation after a research. Situation: - VPS with more than one IPv4 and IPv6 address - IPv4 within the VPS is private class-A only (i.e. 10.x address), so port binding happens to the private Class-A - External IPv4 is linked outside the VPS to the private Class-A - of course, VPS is externally reachable by the external IPv4 - I would like to use a secondary IPv4, i.e. NOT the one, which is shown, when you run the command 'curl -4 icanhazip.com' from within the VPS) - I would like to use a secondary IPv6, i.e. NOT the one, which is shown, when you run the command 'curl -6 icanhazip.com' from within the VPS) Let's assume, for my example only, I have the following secondary IP addresses : - external IPv4 7.8.9.10 - internal IPv4 10.0.0.7 - IPv6 [2345:bad:face::] Let's further assume, my ORPort was 1234 and the obfs4 port was 4321 In order to have TOR distribute the correct bridge line "obfs4 7.8.9.10:4321 <...>", is the following torrc config correct? BridgeRelay 1 ORPort 7.8.9.10:1234 NoListen ORPort 10.0.0.7:1234 NoAdvertise ORPort [2345:bad:face::]:1234 Address 7.8.9.10 Address [2345:bad:face::] OutboundBindAddress 10.0.0.7 OutboundBindAddress [2345:bad:face::] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 10.0.0.7:4321 ExtORPort auto ContactInfo johndoe(a)nowhere.org Nickname MyCoolBridge With this config, I indeed am able to connect to the bridge using the "obfs4 7.8.9.10:4321 <...>" bridge line, but is this line also communicated like that by the bridge distributor, or do I need to adapt the above config to ensure proper distribution? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

5 10

FW: RE: Re: Re: QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 05 Aug '25

05 Aug '25

Seems I only answered to George, instead of all, sorry. ---------------------------------------- Betreff: FW: RE: Re: [tor-relays] Re: QUESTION: OBFS4 on secondary IP and NAT Von: C. Pe. <peca-relay(a)mailfence.com> An: George Hartley <hartley_george(a)proton.me> Datum: 05.08.2025, 14:41:41 I am of course not the expert here. However - NoAdvertise and NoListen are usually combined in two consecutive ORPort statements. This is done to in fact to tell Tor to "listen to ip:port A, but advertise ip:port B", so there definitely is an advertisement of the relay. A relay works fine with that and the "relay piece of a bridge" (so to say) also works well. But yes, there indeed IS some hassle with the bridge distribution (see also my other post, which still waits moderator approval). Question remains: Is that a known "shortcoming" for pluggable transports, or is there a special way needed to configure this properly? So we seem to have two issues with bridge setup, NAT and binding to specific IP: 1. Not possible to properly advertise/distribute obfs4 external IP, if obfs4 port binding to internal IP. 2. In such cases, bridge distribution does not happen. I have, based an observation from another bridge without NAT, even the impression, that specifying a specific IP instead of 0.0.0.0 or [::] in the ServerTransportListenAddr causes a bridge distribution "none". Maybe a bug? C. On August 5, 2025 at 4:46 AM, George Hartley <hartley_george(a)proton.me> wrote: Is this not the purpose of NoAdvertise? You use that flag if you want a private bridge (for example, to give to your friends). Using both NoAdvertise and NoListen on an OBFS4 bridge behind NAT can make BridgeDB treat your bridge as “no distribution.” Because NoAdvertise strips the bridge descriptor from publication, and NoListen prevents the ORPort from binding on your public interface, BridgeDB can’t see or test your bridge. As a result, it marks its distribution status as “None.” The easiest fix is to forward your ORPort through NAT and remove (or at least temporarily disable) those flags so your bridge descriptor is published and reachable. Once BridgeDB can reach and verify your ORPort, it will resume distributing your bridge normally. If you’d like more control, you can also set a specific BridgeDistribution method (for example, moat) in your torrc. Regards George On Tuesday, August 5th, 2025 at 3:46 AM, Gary C. New via tor-relays <tor-relays(a)lists.torproject.org> wrote: I'm seeing a similar issue with a recently configured OBFS4 bridge using NAT, NoAdvertise, NoListen, and distribution status displaying as "None." On Sunday, August 3, 2025 at 12:36:37 PM MDT, C. Pe. via tor-relays <tor-relays(a)lists.torproject.org> wrote: Is there maybe another issue with rdsys being "stuck" ? I have again a new/renewed bridge in distribution status "None" since some days and https://bridges.torproject.org/status?id=<fingerprint> shows for all bridges the last testing two days ago (According to your below statement, updates should appear latest after 4h) Thanks & regards, C. Am 31.07.2025 um 13:12, meskio via tor-relays <tor-relays(a)lists.torproject.org> schrieb: You can always check if the bridgeline distributed by rdsys is correct by visiting: https://bridges.torproject.org/status?id=<your hashed or not fingerprint> This should display one bullet point per IP/transport, so in your case two, one for IPv6 and another for IPv4. Take into account that it might take up to 4h for this page to be updated when you do changes. -- Sent with https://mailfence.com Secure and private email _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

2 1