- tor-relays - lists.torproject.org

I was banned from PayPal
by potlatch 12 Mar '21

12 Mar '21

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

10 9

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

09 Mar '21

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

4 4

Bridge operator iat_mode setting
by torjoy 04 Mar '21

04 Mar '21

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

9 14

difficulty installing
by potlatch 03 Mar '21

03 Mar '21

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

3 2

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

01 Mar '21

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

4 4

Re: [tor-relays] bug message from 02/28/2020 on 4.5.6
by William Kane 01 Mar '21

01 Mar '21

Hi Matt, this is non fatal and as you can see by the most recent log entries, you could ignore it - anyway, some contributor warned about this occurring with more recent tor builds since the way tor probes for listening sockets has changed / it now always binds to all IPv4 & IPv6 addresses and then does reachability checks for each? It was something along the lines of that. What if you manually specify your listening IP addresses and port like I do: ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 This should satisfy tor, at least it does on 0.4.4.6 which is the newest version available through the official ArchLinux repositories, not sure about 0.4.5.x branch which states the following in it's change log: This release series introduces significant improvements in relay (IPv6) address discovery. That would be much safer and cleaner than tor trying to guess which addresses it's supposed to bind to anyway :-) Thank you for running a relay! Best Regards, William 2021-03-01 12:49 GMT, William Kane <ttallink(a)googlemail.com>: > Hi Matt, > > this is non fatal and as you can see by the most recent log entries, > you could ignore it - anyway, some contributor warned about this > occurring with more recent tor builds since the way tor probes for > listening sockets has changed / it now always binds to all IPv4 and > IPv6 addresses an does reachability checks for each? > > It was something along the lines of that. > > What if you manually specify your listening IP addresses and port like I > do: > > ORPort 37.157.195.83:38619 > ORPort [2a02:2b88:2:1::3239:0]:38619 > > This should satisfy tor, at least it does on 0.4.4.6 which is the > newest version available through the official ArchLinux repositories, > not sure about 0.4.5.x branch which states the following in it's > changelog: > > This release series introduces significant improvements in relay > (IPv6) address discovery. > > That would be much safer and cleaner than tor trying to guess which > addresses it's supposed to bind to anyway :-) > > Hope I helped, > William > > > > 2021-02-28 15:28 GMT, tor <tor(a)kevinandmatt.com>: >> Hi All, >> This popped up today after running successfully for about a week. >> -matt >> >> >> x 09:32:50 [NOTICE] Self-testing indicates your ORPort *.*.*.*:443 is >> reachable from the outside. Excellent. Publishing server descriptor. >> x 09:32:50 [NOTICE] Now checking whether IPv4 ORPort *.*.*.* :443 is >> reachable... (this may take up to 20 minutes -- look for log messages >> indicating success) >> x 09:32:26 [NOTICE] External address seen and suggested by a directory >> authority: *.*.*.* >> x 09:30:52 [NOTICE] Bootstrapped 100% (done): Done >> x 09:30:52 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a >> Tor >> circuit >> x 09:30:52 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake >> finished with a relay to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 89% (ap_handshake): Finishing handshake >> with a relay to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 85% (ap_conn_done): Connected to a >> relay >> to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 80% (ap_conn): Connecting to a relay to >> build circuits >> x 09:30:52 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough >> directory info to build circuits >> x 09:30:51 [NOTICE] Bootstrapped 68% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:51 [NOTICE] Bootstrapped 63% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:51 [NOTICE] Bootstrapped 55% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:50 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:50 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking >> for >> relay descriptors >> x 09:30:50 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a >> relay done >> x 09:30:50 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a >> relay >> x 09:30:50 [WARN] Bug: >> /usr/lib/aarch64-linux-gnu/libevent-2.1.so.6(+0x21a10) [0xffff8575ba10] >> (on >> Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x81854) [0xaaaae3745854] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x21419c) [0xaaaae38d819c] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(consider_publishable_server+0x5c) >> [0xaaaae377099c] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(router_rebuild_descriptor+0x90) >> [0xaaaae3770588] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) >> [0xaaaae377016c] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0xabaa0) [0xaaaae376faa0] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1a8) >> [0xaaaae38d6bb0] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) >> [0xaaaae37c15dc] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(log_backtrace_impl+0x68) >> [0xaaaae37b5fc0] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: Tor 0.4.5.6: Non-fatal assertion !(!ei) failed in >> relay_addr_learn_from_dirauth at >> ../src/feature/relay/relay_find_addr.c:235. Stack trace: (on Tor 0.4.5.6 >> ) >> x 09:30:50 [WARN] tor_bug_occurred_(): Bug: >> ../src/feature/relay/relay_find_addr.c:235: >> relay_addr_learn_from_dirauth: >> Non-fatal assertion !(!ei) failed. (on Tor 0.4.5.6 ) >> x 09:30:50 [NOTICE] Unable to find IPv4 address for ORPort 443. You >> might >> want to specify IPv4Only to it or set an explicit address or set Address. >> x 09:30:50 [NOTICE] Opened Control listener connection (ready) on >> /run/tor/control >> qj 09:30:50 [NOTICE] Opening Control listener on /run/tor/control >> >

1 0

bug message from 02/28/2020 on 4.5.6
by tor 28 Feb '21

28 Feb '21

Hi All, This popped up today after running successfully for about a week. -matt x 09:32:50 [NOTICE] Self-testing indicates your ORPort *.*.*.*:443 is reachable from the outside. Excellent. Publishing server descriptor. x 09:32:50 [NOTICE] Now checking whether IPv4 ORPort *.*.*.* :443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) x 09:32:26 [NOTICE] External address seen and suggested by a directory authority: *.*.*.* x 09:30:52 [NOTICE] Bootstrapped 100% (done): Done x 09:30:52 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a Tor circuit x 09:30:52 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 80% (ap_conn): Connecting to a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits x 09:30:51 [NOTICE] Bootstrapped 68% (loading_descriptors): Loading relay descriptors x 09:30:51 [NOTICE] Bootstrapped 63% (loading_descriptors): Loading relay descriptors x 09:30:51 [NOTICE] Bootstrapped 55% (loading_descriptors): Loading relay descriptors x 09:30:50 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors x 09:30:50 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors x 09:30:50 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done x 09:30:50 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay x 09:30:50 [WARN] Bug: /usr/lib/aarch64-linux-gnu/libevent-2.1.so.6(+0x21a10) [0xffff8575ba10] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x81854) [0xaaaae3745854] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x21419c) [0xaaaae38d819c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(consider_publishable_server+0x5c) [0xaaaae377099c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(router_rebuild_descriptor+0x90) [0xaaaae3770588] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) [0xaaaae377016c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0xabaa0) [0xaaaae376faa0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1a8) [0xaaaae38d6bb0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) [0xaaaae37c15dc] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(log_backtrace_impl+0x68) [0xaaaae37b5fc0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: Tor 0.4.5.6: Non-fatal assertion !(!ei) failed in relay_addr_learn_from_dirauth at ../src/feature/relay/relay_find_addr.c:235. Stack trace: (on Tor 0.4.5.6 ) x 09:30:50 [WARN] tor_bug_occurred_(): Bug: ../src/feature/relay/relay_find_addr.c:235: relay_addr_learn_from_dirauth: Non-fatal assertion !(!ei) failed. (on Tor 0.4.5.6 ) x 09:30:50 [NOTICE] Unable to find IPv4 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. x 09:30:50 [NOTICE] Opened Control listener connection (ready) on /run/tor/control qj 09:30:50 [NOTICE] Opening Control listener on /run/tor/control

1 0

Relay metrics - chart never populates
by marsbanks 27 Feb '21

27 Feb '21

Does anyone know why I never see any data in the chart showing the number of clients using my bridge over time? https://metrics.torproject.org/rs.html#details/A675511F2F8EDD6974C3C093B8F3… I'm just concerned I haven't configured something correctly. Thanks. Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

current requirements for Fast and HSDir flags
by Scott Bennett 26 Feb '21

26 Feb '21

What are the current requirements to get an HSDir flag assigned to a relay? MYCROFTsOtherChild has, at last heartbeat message, been up for 35 days and 7 hours. To the best of my knowledge, it has not had an HSDir flag in the consensus at any time since it was last started more than a month ago. What are the current requirements to get a Fast flag assigned to a relay? MYCROFTsOtherChild often runs busily at 330 KB/s to 350 KB/s. Sometimes since it was last started over a month ago it has had a Fast flag in the consensus, and at other times it has not. The Fast flag seems to come and go like the wayward breezes. The Bandwidth= value in the consensus entry for MYCROFTsOtherChild has varied from somewhere in the 30s to the 110s, AFAI have seen, but is always subject to the delayed effects of the presence or absence of the Fast flag, of course, and prior to the currently running instance has also been subject to the presence or absence of the HSDir flag. The authorities have seemed to be acting more or less at random when assigning flags for the consensus for many months. Does the tor project envision any timeline for a return to rational, predictable behavior on the part of the authorities? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

Re: [tor-relays] IPv6
by Dr Gerard Bulger 25 Feb '21

25 Feb '21

Thinking of IPv6: How far has the team got in implementing IPv6 only OR port facility ? Currently you can only run tor relay of any sort if there is open IPv4 OR port to the internet. This is getting a bit quaint. I am sure I am not alone in having much wasted bandwidth that could be put to good Tor use but they are only accessible via IPv6, while they can exit of course IPv4 and IPv6 I realise that so far, despite IPv6 being open on my main exit for some years, there is still little IPv6 traffic, but that might suddenly change. Gerry From: tor-relays <tor-relays-bounces(a)lists.torproject.org> On Behalf Of Onion Operator Sent: 24 February 2021 10:08 To: tor-relays(a)lists.torproject.org Subject: [tor-relays] IPv6 auto-discovery vs. privacy extensions Saluton, My relay started to log this message since 0.4.5.5: Auto-discovered IPv6 address [...]:443 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] I think it started with the introduction of IPv6 auto-discovery. The problem, as I understand it, is that my relay has IPv6 privacy extensions enabled and therefore the IPv6 detection logic gets fooled. Indeed the IPv6 I see in the logs is one of the temporary addresses used as client towards other relays. Relevant config is: ORPort 443 IPv4Only ORPort [...]:443 IPv6Only I added the IPv{4,6}Only options only in searching a solution to this problem, before 0.4.5.5 the IPv6 relay worked perfectly without. In reading the documentation of AddressDisableIPv6 I got the impression that if (any?) ORPort is configured with IPv4Only the IPv6 auto-discovery gets disabled but evidence does not support my understanding. Is it a bug? Any other way to disable IPv6 auto-discovery? -- flev

4 5