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=
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
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/
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
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
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?
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
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