July 2020 - tor-relays - lists.torproject.org

Call for Testing - New Feature: Relay IPv6 Address Discovery
by David Goulet 28 Nov '20

28 Nov '20

Greetings everyone! We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment. This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature. The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order): 1. "Address" from torrc 2. "ORPort address:port" from torrc 3. Interface address. First public IPv6 is used. 4. Local hostname, DNS AAAA query. If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory). The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now. Thus this is now valid: Address 1.2.3.4 Address [4242::4242] ORPort 9001 Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort. Now, if you happen to have this configuration which I believe might be common at the moment: ORPort 9001 ORPort [4242::4242]:9001 The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this. Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family: ORPort <IPv4>:9001 ORPort <IPv6>:9001 And of course, if you want your relay to _not_ listen on IPv6: ORPort 9001 IPv4Only In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from. Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it. Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated. Thanks!! David [1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en -- EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=

8 12

Heartbeat: It seems like we are not in the cached consensus.
by Fran 27 Sep '20

27 Sep '20

Hello, I'm taking care of a server of a friend who's on holiday. The server is up and running but not part of the consensus. As beeing instructed I updated to the lastest OpenBSD snapshot when I saw that a new tor release is available (Tor 0.4.3.5 on OpenBSD). Excerpts from the log: Jul 13 20:04:02.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jul 13 20:05:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jul 13 20:05:35.000 [notice] Performing bandwidth self-test...done. Jul 14 02:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 02:04:01.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 2.04 MB and received 6.25 MB. Jul 14 02:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 33% Jul 14 02:04:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor. Jul 14 02:04:01.000 [notice] Since startup we initiated 0 and received 157 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 5 v4 connections; initiated 48 and received 124 v5 connections. Jul 14 02:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 06:04:02.000 [notice] Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 4 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections. Jul 14 08:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 08:04:01.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 1 circuits open. I've sent 3.46 MB and received 11.22 MB. Jul 14 08:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 47% Jul 14 08:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1/1 NTor. Jul 14 08:04:01.000 [notice] Since startup we initiated 0 and received 340 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 10 v4 connections; initiated 57 and received 246 v5 connections. Jul 14 08:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 14:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 14:04:01.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 4.89 MB and received 15.33 MB. Jul 14 14:04:01.000 [notice] Average packaged cell fullness: 26.760%. TLS write overhead: 51% Jul 14 14:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 6/6 NTor. Jul 14 14:04:01.000 [notice] Since startup we initiated 0 and received 493 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 18 v4 connections; initiated 64 and received 370 v5 connections. Jul 14 14:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Atlas show the server as down: https://metrics.torproject.org/rs.html#details/AC601DBDB7FBD53454045EDC08DA… Accessing the status page on port 80 works. No FW on the machine. Any ideas? Thanks and regards Fran

4 7

Become a Fallback Directory Mirror (deadline: July 23)
by gus 17 Sep '20

17 Sep '20

Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDire… [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_… -- The Tor Project Community Team Lead http://expyuzz4wqqyqhjn.onion/

26 30

Guard flag got removed after only 48 hours of downtime.
by William Kane 11 Aug '20

11 Aug '20

Please discard the previous (empty) email, it was an error on my end. Today, I noticed that my guard flag has been taken away: https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73A… Does this have to do with the recent two, major downtime's of the relay? While I wasn't monitoring the server, the kernel decided (or rather oom-killer did) to reap the tor process for consuming too much memory (keep in mind, this is a virtual machine with only 1GB of RAM which running another daemon consuming about ~92MB's of RAM). I promptly restarted the relay, but the same thing happened again yesterday. So today, I manually set a lower MaxMemInQueues value instead of letting Tor calculate one for me - 640MB's instead of 732MB's. Still, I am confused as for why the guard flag has been taken away - I recently opted in to be a fallback directory mirror, does this have anything to do with it? The relay was stable and online for almost a year, so only 48 hours of downtime shouldn't affect the variables qualifying a relay to become and stay a guard that much? If this is because of the directory mirror thing, then please take my relay out of that pool - I want to stay a guard for a number of reasons - mainly because my host is only hosting about 10 tor relays unlike all the other big hosters that are commonly used - network variety is very important or so I've been taught, especially when it comes to guard relays. If this is a mistake on Tor Project's end, I please ask for it to be resolved - however, if it's the Directory Authorities disqualifying my relay, then there's nothing to be done except to wait. Greetings, William Kane

5 11

What is the command to view the tor log file on Debian?
by Keifer Bly 08 Aug '20

08 Aug '20

6 8

Should I use Tor Alpha on my relays
by Sebastian Elisa Pfeifer 01 Aug '20

01 Aug '20

Hello, I am currently running Tor from the Tor Repositories on Debian Stable. Its working ok, but I was wondering if the network would benefit if I would start using Tor Alpha? Greetings, Sebastian

3 3

Upgrading Linux Mint to Ulyana
by Anonforpeace 30 Jul '20

30 Jul '20

Hello: I am running my bridge on Linux Mint and there is an upgrade to the latest version, Linux Mint 20, Ulyana. I'd like to perform the upgrade, buy my question is, is there a way to do it without having to reconfigure the bridge entirely?

2 1

Guard flag got removed after only 48 hours of downtime.
by William Kane 28 Jul '20

28 Jul '20

1 0

Recover AccountingMax counter
by Camie Hethcote 28 Jul '20

28 Jul '20

Hi guys ! I had to reset tor service which led to AccountingMax counter reset. I'm already out of traffic limit so can I somehow recover this counter or should I wait until limit reset from my provider and then start tor service again? Thanks ! Camie

1 0

Unable to Automate TOR Browser | Python
by ABDAL LALIT 27 Jul '20

27 Jul '20

Hi, I'm trying to automate TOR Browser for anonymous scraping using python. The code is given below: from selenium import webdriver from selenium.webdriver.firefox.firefox_profile import FirefoxProfile from selenium.webdriver.firefox.firefox_binary import FirefoxBinary binary = FirefoxBinary("C://Tor Browser//Browser//firefox.exe") driver = webdriver.Firefox(firefox_binary = binary) def interactWithSite(driver): driver.get("https://www.google.com") driver.save_screenshot("screenshot.png") This is the preliminary code I used as a building block. I am receiving an error message, while running the code as follows: The pop-up is as [image: image.png] While the error shown in the code is as follows [image: image.png] [image: image.png] [image: image.png] I request the team to kindly help me with this issue. I'm really stuck and thus am unable to build up my project further

1 0